Blazor全栈是个陷阱

前言

大家好，我是曦远~

最近有个项目急着上线

大概就是接受一堆客户端连接上报数据，然后在界面上展示数据和简单的控制

这种场景感觉 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 一样能打