選擇渲染模式前
Blazor 實際上是什麼
Blazor 是 Microsoft 的 .NET Web 應用程式元件框架。您可以從 Razor 元件建立 UI，用 C# 編寫大部分互動邏輯，然後讓 ASP.NET Core 在伺服器、WebAssembly 或本機應用程式 shell 中呈現這些元件。
它源自於較早的 ASP.NET 想法。 Web 窗體試圖將 Web 隱藏在伺服器控制項後面。 MVC 和 Razor Pages 讓請求-回應 HTML 更加清晰。 Blazor 新增了可重複使用的互動元件，但對於簡單的內容頁面和表單來說，它不會讓 MVC 或 Razor Pages 過時。
Web Forms、MVC 和 Razor Pages 解決了不同的問題
Web 表單非常高效，但笨重且有狀態。 MVC 和 Razor Pages 提供了更清晰的 HTML 和更簡單的請求處理。當頁面主要讀取資料、發布表單並返回 HTML 時，它們仍然很好。
元件使 UI 邏輯接近標記
Razor 元件可以包含標記、參數、事件、驗證、注入服務和本機狀態。這對於頁面變更而無需完全重新載入的儀表板、編輯器、精靈、網格和工具非常有用。
現代 .NET 可讓您混合渲染模式
較新的 Blazor 應用程式可以將靜態伺服器渲染的 HTML 與互動式元件結合。這很重要，因為一個頁面可能需要可爬行的內容，而另一部分需要即時元件。
目錄
從這裡開始
有用的簡短版本
Blazor 不是一種架構。它是一個具有多種渲染模式的元件模型。正確的選擇較少取決於語法，而更多取決於狀態、延遲、記憶體和可爬行連結的位置。
Blazor 伺服器是有狀態的
第一次加載時感覺很快，但伺服器保持即時電路。在流量成長之前規劃記憶體、重新連接行為和橫向擴展。
WebAssembly 預先付款
它刪除了即時伺服器電路，但第一次存取會下載運行時和應用程式。快取、修剪和預渲染很重要。
混合動力是產品決策
當應用程式確實需要桌面或移動 shell 時，請使用混合。對於公共內容，請使用 Web 渲染和真實 URL。
Blazor 伺服器模式
Blazor Server 在兩次點擊之間保持工作活動狀態
Blazor Server 不是普通的無狀態請求回應頁面。連接的瀏覽器標籤獲得電路。當使用者連接時，伺服器會保留該電路的元件狀態和範圍服務，並且通常會在斷開連接後的短暫重新連接視窗內保留。
記憶隨著主動電路的增長而增長
每個連接的接頭片都有一個電路。元件狀態、作用域服務、驗證狀態和待處理的 UI 工作可以保留在記憶體中，直到電路結束。負載測試必須計算活躍用戶數，而不僅僅是每秒的請求數。
延遲成為 UI 的一部分
按鈕點擊、輸入事件或網格互動可能會往返伺服器。當觀眾分佈在不同地區時，主持人應靠近用戶並避免聊天內容。
橫向擴展需要一個計劃
多個應用程式實例通常需要黏性會話、SignalR 背板、Azure SignalR 服務或仔細的狀態設計。否則，重新連接和帶電電路可能會出現在錯誤的實例上。
適合：受控用戶
Blazor Server 對於經過驗證的工具、管理螢幕、儀表板和使用者、延遲和託管容量已知的內部應用程式而言最為強大。
Blazor WebAssembly 模式
WebAssembly 將成本轉移到第一次加載
Blazor WebAssembly 消除了伺服器電路，但並沒有消除成本。瀏覽器必須下載 .NET 執行時間、組件、本地化資源和應用程式資產，才能獲得快速體驗。重複訪問可能會很好，因為快取會有所幫助。初次就診需要護理。
第一個負載是稅
瀏覽器下載 .NET 執行時期、應用程式集、資源和靜態資產。修剪有幫助。提前編譯可以改善 CPU 密集型工作，但通常會增加下載大小。
秘密不能存在於客戶端
WebAssembly 應用程式在使用者的瀏覽器中運作。像任何公共前端一樣對待它：在伺服器上保守秘密，保護 API，並假設可以檢查客戶端程式碼。
SEO需要渲染內容
對於公共文章、產品頁面和登陸頁面，不要依賴僅在 WebAssembly 啟動後才變得有用的空白外殼。使用伺服器端渲染、預先渲染、靜態渲染或單獨的內容路徑。
適合：離線或客戶端較多的應用程式
當使用者經常返回、需要離線行為或執行繁重的客戶端工作（而伺服器往返會更糟）時，WebAssembly 效果很好。
混合和 WebView
混合適用於應用程序，不適用於公共登陸頁面
當 .NET 團隊想要在桌面或行動應用程式中重複使用元件時，Blazor Hybrid 非常有用。它透過 WebView 在本機 shell 中運行，因此可以接近本機檔案、設備 API 和企業部署。它不是專注於 SEO 的網站的捷徑。
- 當您需要存取本機檔案、裝置 API、桌面部署或行動裝置打包時，請使用混合。
- 不要選擇混合只是為了重複使用 Web 元件。本機 shell 新增了更新、儲存、簽章和支援工作。
- 對於 SEO 和可共享的公共 URL，混合通常是錯誤的表面。
多語言路由
具有文化意識的連結必須是真實的鏈接
多語言 Blazor 網站不應在頁面變成互動式後僅在點擊處理程序或 JavaScript 中建立語言導航。搜尋引擎和使用者需要在初始 HTML 中提供真正的錨標記，以及穩定的 href 值、規範 URL 和 hreflang 資料。
- 使用中央頁面連結和幫助程序，而不是手動建立的字串，例如斜線文化斜線路徑。
- 在初始 HTML 渲染期間，將語言連結渲染為具有 href 值的錨標記。
- 保持規格 URL、hreflang URL 和可見光語言導航同步。
- 避免將重要連結隱藏在 onclick 處理程序、延遲的 JavaScript 或純互動式 Blazor 狀態後面。
決策指南
根據您接受的瓶頸進行選擇
每種渲染模式都會將壓力轉移到不同的地方。選擇你可以衡量、主持並向團隊解釋的壓力。
首次載入和 .NET 後端整合何時最重要
為受控的身份驗證應用程式選擇 Blazor 伺服器，其中伺服器記憶體、即時連接和區域延遲是可以接受的營運成本。
當客戶的工作和線下行為最重要時
當重複存取、快取、離線使用或本機 CPU 工作比最小的首次負載更重要時，請選擇 WebAssembly。
當產品確實是原生應用程式時
當應用程式屬於桌面或行動裝置並且比公共網路覆蓋範圍更需要本地整合時，請選擇混合。
當網站主要是文件和表格時
對於內容較多的網站、公開文件和互動性有限的表單來說，經典 ASP.NET Core MVC 或 Razor 頁面通常更簡單。
參考部分
當你真正建立這個時，請閱讀接下來的內容
這些參考在做出架構決策後非常有用，因為它們涵蓋了使 Blazor 頁面在生產中可靠的部分：元資料、語言連結、託管和可重複使用 UI。
當每個頁面需要一致的標題、描述、開放圖譜、規格和 JSON-LD 輸出時，請使用此選項。
SEO 友善的語言-區域連結當多語言路由需要真正的可爬行連結、穩定的文化路徑和正確的 hreflang 輸出時，請使用此選項。
在 UpCloud 主機架設 Blazor當 Blazor 伺服器應用程式需要小型 VPS、Nginx、TLS、systemd、日誌、備份和可重複部署時，請使用此選項。
TablerForNet當值是管理介面、資料表、表單和儀表板螢幕而不是行銷頁面時，請使用此選項。
Blazor如果您希望在選擇下一個實作細節之前將相關指南放在一個位置，請使用 Blazor 中心。
常見問題
為什麼 Blazor Server 需要比 MVC 更多的記憶體？
MVC可以完成一個請求並釋放大部分請求狀態。 Blazor Server 為每個連線的瀏覽器標籤保留一條線路，因此元件狀態和作用域服務可以在按一下之間保持活動狀態。
我可以在多個應用程式實例上執行 Blazor Server 嗎？
是的，但是要仔細規劃。即時電路和 SignalR 連接需要穩定的路由、背板或託管 SignalR 服務以及能夠正確重新連接的應用程式狀態。
Blazor WebAssembly 適合 SEO？
是的，但不是通過運送一個空殼並希望爬蟲等待。公共頁面需要在第一次回應之前或期間呈現 HTML、元資料、規範連結和結構化資料。
應如何建立多語言 Blazor 連結？
使用中心路線定義並為每種文化呈現真實的錨標記。保持可見連結、規範 URL 和 hreflang 資料對齊，以便使用者和爬蟲看到相同的語言結構。