原文标题：React Won by Default – And It’s Killing Frontend Innovation
发布日期：2025-09-16
修订：2025-10-04本文尝试说明：React-by-default 有隐性成本。在选择框架时，应该做“刻意选择”，而不是出于惯性。
React 早已不再靠技术优势取胜。今天它的胜利更多来自“默认选择”。而这种默认，正在拖慢整个前端生态的创新速度。
当团队需要做一个新的前端时，讨论很少从“约束是什么、哪种工具最合适？”开始。它更常见的开场是：“用 React 吧，大家都会。”这种反射式选择会形成自我强化的循环：决定架构的是网络效应，而不是技术适配度。
与此同时，具有新架构思路的框架很难被采用。Svelte 通过编译期优化配合运行时信号，让包体更小；Solid 在没有虚拟 DOM 额外负担的情况下实现细粒度响应式；Qwik 通过 resumability（可恢复性）实现几乎瞬时启动。它们在常见场景里可以胜过 React 的模型，但因为 React 被“默认选中”，它们很少得到公平评估。
React 在很多方面都很出色。问题不在 React 本身，而在“默认用 React”的心态。
创新天花板
React 的技术基础解释了今天的一部分摩擦。虚拟 DOM 在 2013 年是个聪明的解决方案，但正如 Rich Harris 在《Virtual DOM is pure overhead》中所说，它引入了大量现代编译器往往可以避免的工作。
Hooks 解决了 class 组件时代的痛点，但也带来新的复杂度：依赖数组、陈旧闭包（stale closures）、被滥用的 effect。即便 React 官方文档也反复强调克制：“You Might Not Need an Effect”。Server Components 可以减少客户端 JavaScript，并允许只在服务端访问数据，但同时引入架构复杂度和新的失败模式。
React Compiler 是个聪明的方案，它把 useMemo/useCallback 之类的模式自动化。但它的存在也在传递一个信号：我们正在围绕模型内生的约束做优化。
2025 年 10 月发布的 React 19.2 继续沿着这条路走。新的 useEffectEvent Hook 专门用来解决 effect 里依赖数组的问题——这相当于给 Hooks 自己制造的复杂度打补丁。Svelte 和 Solid 也有类似的 untrack 能力，但它们默认采用自动依赖追踪，只在边缘场景才需要 untrack；而 React 需要在每一个 effect 里手工维护依赖数组，然后再引入 useEffectEvent 来绕开这种模型的限制。
同一个版本还引入了用于管理应用可见/隐藏状态的 <Activity /> 组件，以及新的部分预渲染 API。每一次新增都会扩大开发者必须掌握的 API 面，而其他框架往往能用更简单的原语达到相近的效果。
对比一下这些替代路线：Svelte 5 的 Runes 用运行时信号实现细粒度响应式；Solid 的细粒度响应式只更新真正发生变化的部分；Qwik 的 resumability 消除了传统意义上的 hydration。它们不是对 React 模型的渐进式修修补补，而是不同的模型、不同的上限。
没有被采用的创新，不会改变结果。而当选择出于“反射”，采用就不会发生。
我们共同背负的技术债
默认选择 React，常常意味着把一套我们已经不再质疑的运行时与协调（reconciliation）成本一起打包带走。即使它“够快”，天花板也仍然低于编译期方案或细粒度响应式模型。开发者把时间花在管理重渲染、effect 依赖和 hydration 边界上，而不是交付价值。性能研究的结论也一致：关键路径上的 JavaScript 很昂贵（The Cost of JavaScript）。
除了性能，我们还把心智模型中心从“Web 基础”挪到了“React 模式”，降低了技能的可迁移性，也更容易形成架构惰性。损失的不只是性能，更是机会成本：当更合适的替代方案从未被评估时，我们就错过了它们。
被扼杀的框架
Svelte：信号 + 编译期优化
Svelte 5 把运行时信号用于细粒度响应式，并配合激进的编译期优化：没有虚拟 DOM，运行时比 React 更小。组件会被编译成高效、定向的 DOM 操作，心智模型也更贴近 Web 基础。
但“没有足够岗位”的叙事，让 Svelte 即便在很多用例里技术更强，也仍被人为压低了采用率。现实案例（例如 The Guardian 在其前端采用 Svelte）显示，它能显著提升性能与开发效率，带来更小的包体与更快的加载速度。比如 Wired 的一篇文章提到，开发者 Shawn Wang（@swyx on X/Twitter）利用 Svelte 的编译期优化，把自己网站从 React 的 187KB 降到 Svelte 的 9KB，这会让慢网环境下的体验大幅改善。
Solid：响应式原语路线
Solid 在保留 JSX 熟悉感的同时，提供细粒度响应式：更新通过信号直接流向受影响的 DOM 节点，绕开协调带来的瓶颈。性能特征强，但心智占有率有限。正如 Solid 的对比指南所阐述，这种精确响应式能比 React 的虚拟 DOM 更高效地更新，减少无谓工作，并以更简单的状态管理改善开发体验。
Solid 的公开成功案例不如“更主流”的框架多，这在很大程度上也源于它的采用率较低。但早期采用者的口碑反馈显示，它同样可能带来更新效率与代码简洁性的质变，只是仍在等待更多团队去试、去规模化验证与传播。
Qwik：可恢复性（Resumability）的创新
Qwik 以 resumability 取代 hydration：通过只加载当前交互所需的代码，实现几乎瞬时启动。这要求应用状态可序列化，会带来架构上的约束，但能换来可量化的性能收益。它尤其适合内容型站点、慢网环境或移动优先应用。根据 Qwik 的 Think Qwik 指南，这通过渐进式加载以及对状态与代码的序列化来实现：应用无需沉重的客户端启动过程即可立刻恢复执行，因此相较传统框架有更好的可扩展性与更低的首屏成本。
Qwik 的成功故事不够显眼，可能只是因为更少团队愿意跳出默认去尝试。但真正试过的人报告了启动时间与资源效率的显著改善，这意味着一旦采用率上升，潜在的价值会被更多释放出来。
这三者之所以被低估，并不是因为它们不够好，而是因为“默认选择”阻断了尝试它们的机会。
此外，React 的 API 面明显更大、更复杂：Hooks、Context、Reducer、各种 memo 化模式……都需要谨慎管理才能避坑。这会抬高开发者的认知负担，进而带来因为误解依赖关系或过度工程而产生的缺陷。比如 Cloudflare 在 2025 年 9 月 12 日的一次故障中，一个 useEffect 中有问题的依赖数组触发了重复 API 调用，压垮了他们的 Tenant Service，导致大范围失败。相比之下，Svelte、Solid、Qwik 的 API 往往更小、更聚焦，更强调简洁与 Web 基础，降低了上手与维护成本。
网络效应的牢笼
React 的主导地位会自我强化。招聘启事写的是“React 开发者”，而不是“前端工程师”，从而限制了技能多样性。组件库、团队肌肉记忆与组织惯性进一步加固了这种路径依赖。
风险规避的管理者会选择“更安全”的选项；学校教的是岗位要求的内容；循环与技术优劣无关地继续运转。
这不是健康竞争，而是“默认选择”对生态的捕获。
打破网络效应
逃离这种状态需要多层面的主动行动。技术负责人应该基于约束与技术优劣做选择，而不是追随势能；公司可以划出一小部分创新预算，用来尝试替代方案；开发者也可以在单一心智模型之外持续进修。
教育者可以在教授具体工具的同时，强化框架无关的概念；开源贡献者可以帮助替代生态走向成熟。
变化不会自动发生，它需要有意识的选择。
框架评估清单
在启动新项目时，用下面这份简单清单来做“刻意选择”：
- 性能需求评估：关注启动时间、更新效率、包体积等指标；如果速度是关键，优先考虑编译期优化更强的框架。
- 团队技能与学习曲线：尊重既有经验，但也要把迁移路径纳入考虑；许多替代方案有温和上手路径（例如 Solid 与 React 的 JSX 兼容）。
- 规模化与持有成本：计算长期成本，包括维护、依赖管理与技术债；替代方案往往能减少运行时开销，从而降低托管成本并提升可扩展性。
- 生态适配：在成熟与创新之间平衡；先在非关键路径试点，用以验证迁移可行性与 ROI。
常见反驳
“但生态成熟度呢！” 成熟很有价值，也可能固化惰性。年龄不等于适配当下约束。
此外，一个成熟生态往往意味着对第三方包的重度依赖，这会引入维护负担：依赖升级、安全漏洞、以及因为未使用代码而膨胀的包体。虽然在某些场景里不可避免，但这种灵活性也容易变成过度依赖；围绕具体需求打造的定制化方案通常更轻、更易维护。替代框架的小生态反而鼓励从基础出发，形成更深的理解与更少的技术债。并且在 AI 编码助手可以按需生成精确自定义函数的今天，打造“为应用量身定制”的轻量工具函数的门槛已经显著降低，这让我们有可能完全避开像 lodash、Moment 或 date-fns 这类通用库，转而使用更轻的实现。
“但招聘呢！” 招聘跟着需求走。你可以先在非关键路径试点替代方案，降低风险；再以“基础能力 + 在岗训练”的方式招聘。
“但组件库呢！” 组件库往往是膨胀的代名词，主要在交付速度压倒一切时才最有用。围绕应用真实需求构建组件，会更精简，因为你不会为自己没有的问题打包代码。框架无关的设计系统与 Web Components 也能在保留交付速度的同时降低锁定风险。
“但稳定性呢！” React 从 class 到 Hooks、再到 Server Components、再到 React 19.2 的 useEffectEvent 与 <Activity />，展示的是持续 churn，而不是稳定。许多替代框架反而提供更一致的 API。
“但大规模验证过呢！” jQuery 也曾被大规模验证过。过去的成功并不保证未来仍然相关。
更广泛的生态伤害
当一个框架的约束变成事实上的限制时，单一化会让 Web 演化放缓。人才把精力花在解决框架特有的问题上，而不是推动平台向前。资本也会不论技术优劣地追随既有赢家。
课程体系为了“立刻可就业”而不是“长期可迁移”，会优化成框架特定技能；平台层面的改进也可能被延后，因为“React 能解决”成了默认答案。
当多样性消失，整个生态都会受损。
我们本可以培育的花园
健康生态需要多样性，而不是单一栽培。创新来自不同路线的竞争与交叉授粉。开发者通过学习多个心智模型成长；平台也会在不同框架的推动下突破边界。
把所有筹码押在一个模型上，会制造单点失败。如果它触及硬性上限会怎样？如果我们从未探索替代方案，又错过了哪些机会？
是时候基于约束与技术优劣，而不是势能，来选择框架了。你的下一个项目不该被“默认用 React”绑架；生态也值得拥有只有多样性才能带来的创新。
不要再默认种同一种种子。通过探索多样化的框架，我们能培育出更韧性、更具创新力的花园，而不是我们已逐渐滑向的单一栽培。
选择权在我们手里。