前言

大家好，我是曦遠~

最近有個項目急著上線

大概就是接受一堆客戶端連接上報數據，然后在界面上展示數據和簡單的控制

這種場景感覺 Blazor 還挺合適的，折騰之心蠢蠢欲動

于是掏出了 Blazor 開搞

現在 .NET9 的 Blazor 已經進化了，像 Next.js 那樣可以把 server 和 client 放在同一個項目里跑，不過還是差了點，WebAssembly 的 client 必須單獨一個 project

也很好理解，WebAssembly 畢竟是一個單獨的程序集，要分發到瀏覽器端運行的

不過搞了半天，我后面還是放棄了

在意識到浪費了太多時間之前，我及時跳坑了??

PS: 文章只是個人觀點，僅代表作者自己的看法，不喜勿噴

原因

原因有幾個方面

生態問題

Blazor 的組件庫有點缺乏，我傾向于使用 Tailwind CSS 組件庫，這點要給 Flowbite 點個贊，不僅提供了支持，還開了個官方的 Flowbite-Blazor 項目，不過還處在早期開發狀態；還有一個 LumexUI，雖然 star 不多，但組件方面已經挺完善的了，可堪一用。

這么一看，生態似乎還好，反正都是用 Tailwind CSS，缺少的組件我自己封裝就完事了，還可以搭配 JSInterop 實現交互。

如果在幾年前，確實是這樣的。

但是，「大人，時代變了」，我之前也很多次說到了，現在是 AI 時代了，什么是 AI 時代？就是要盡可能利用好 AI 去做一些重復性的、不重要的工作。

在我看來封裝常用組件，做簡單的頁面布局，這些工作完全可以交給 AI 生成，之后再自己改一改，這樣才能提高效率。

也正是因為生態問題，AI 對 Blazor 的支持比較有限，比起前端技術棧，AI 體驗相差較多。

穩定性問題

這里不是說框架的穩定性

是文檔、API的穩定性

Blazor 還在發展中，很多功能和寫法變化太快，就像 Auth 一樣，變來變去的，現在讓 AI 生成還可以拿幾個大版本之前的寫法來糊弄我，這不是坑我嗎??

之前大家總說前端更新得太快，學不動了

但前端變來變去，還是那些東西，無非就是 JavaScript 和 CSS

但前端變來變去，還是那些東西，無非就是 JavaScript 和 CSS。

React 這樣的框架，JSX 完全就是在寫 JavaScript。

Tailwind CSS 歸根到底還是 CSS。

而 Blazor 就不一樣了 —— 它的生態和寫法會直接跟著 .NET 版本走，每次 .NET 發大版本，API 改動幅度不小。

于是可能經常會遇到「文檔和示例用的是舊寫法」「AI 生成的代碼直接跑不通」「StackOverflow 上的答案全是過時的」。這種不確定性會導致開發效率大打折扣。

全棧的錯覺

Blazor 最大的賣點就是「全?！梗梢郧昂蠖硕紝?C#，不用管 JS，不用折騰 Node，不用 npm/yarn/pnpm，不用面對一大堆前端工程化配置，看起來很美好。

但這其實是個陷阱。

因為你終究還是要面對前端世界。

• 你要做炫酷交互，最后繞不開 JavaScript；
• 你想接入成熟的前端庫（比如圖表、富文本編輯器），要么等社區封裝，要么自己寫 JSInterop；
• 你要優化構建、部署、SEO、SSR，Blazor 的那套體系就沒法和 Next.js、Nuxt 這種前端框架相比。

換句話說，Blazor 的「全棧」更像是「把前端盡量弱化」，但不是「完全替代前端」。這就像是「你以為不用學 JS 了，其實你只是不知道你哪天會被微軟教做人」。

學習成本與團隊問題

還有一個現實點的因素：團隊。

前端工程師基本都熟悉 React/Vue/Svelte 這一類技術棧，而 Blazor 在前端圈幾乎是小透明。要是做個人項目，折騰折騰還行；但要是做團隊協作，Blazor 直接勸退大部分前端。

而且 AI 在 React/Vue 這類主流框架上已經能給到非常成熟的支持，從代碼生成、Bug 定位到最佳實踐提示，幾乎就是「你的副駕」。但在 Blazor 上，AI 的幫助有限，很多時候還會給你錯的答案。

這就意味著，Blazor 看起來能統一語言，實際上卻可能把你鎖死在一個「別人幫不上忙」的生態里。

性能與部署

再說個我遇到的小坑：WebAssembly。

Blazor WebAssembly 本質上是把 .NET runtime 搬進瀏覽器跑，再加載程序集。第一次加載的時候，體積往往是幾十 MB 起步。雖然現在有 AOT 和壓縮，但體驗還是不如主流前端框架。

Blazor Server 模式雖然輕量，但是需要長連接（SignalR），一旦并發量上去，服務器壓力會非常大。等用到生產環境，就會發現「小 demo 可以，真要跑業務就得掂量掂量」。

不過 Server 模式在我這次的項目里非常合適，這種項目用的人不多，不會有太大的服務器壓力，Blazor 提供的數據交互和長連接優勢還是很明顯的，可惜沒能駕馭哈哈哈??

小結

Blazor 并不是一個壞框架，它在某些場景下確實很合適，比如：

• 內部工具 / 管理后臺；
• 小團隊 / 個人項目；
• 對 .NET 技術棧高度依賴的公司。

但是，如果你想用「Blazor 全?！谷ヌ娲髁髑岸藯?，甚至幻想著「一個人寫 C# 就能搞定所有 Web 項目」，那大概率會掉坑里。

它解決了一部分問題，但引入了更多潛在的坑。??

全棧不是陷阱，「Blazor 全棧」才是陷阱。

所以我的建議是：如果喜歡 C#，用 Blazor 做一些小工具是挺爽的。但如果要做嚴肅的生產項目，尤其是需要長期維護、團隊協作、快速迭代的項目，還是乖乖用 React / Vue / Angular 吧，別和自己過不去。

不過 Blazor 的潛力我還是很看好的，或許有一天，Blazor 全棧能和 Next.js 一樣能打??