React 仍是使用最广的前端框架，但它在大型项目中的几个痛点，是社区反复讨论的真实话题。本文按问题域整理这些论点，不提供结论性的"替代方案"，只列事实与观点来源。

1. 性能：虚拟 DOM 的边际收益在下降

虚拟 DOM 的核心价值是减少直接 DOM 操作的次数。但当页面数据量大、更新频繁时，diff 计算和协调本身会成为开销。React 团队通过 Fiber、并发特性（Concurrent Features）持续优化，但优化手段（memo、useMemo、useCallback）需要开发者主动维护，容易遗漏或误用。

业界普遍观点：虚拟 DOM 对中小型页面收益明显，对高频交互的大数据量场景，收益会打折扣。React Compiler（自动记忆化）是官方对此问题的回应，但截至本文写作时尚未成为默认方案。

2. 复杂度：Hooks 规则与状态管理的认知负担

React 的 API 面在 2016 年之后快速膨胀：Hooks 规则、并发模式、Suspense、Server Components。每一项都有合理动机，但组合起来的学习曲线明显变陡。状态管理生态（Redux、Zustand、Jotai、XState）长期分裂，团队需要在多个范式间做选择并保持一致。

这一点本身不是缺陷，而是框架演进的自然结果。但对中小团队而言，“写业务代码的时间被框架概念占用"是真实感受，也是 Svelte 等框架主打"少概念"的卖点来源。

3. 人才成本：熟练开发者供不应求

React 开发者基数大，但"能驾驭大型 React 项目"的熟练开发者仍然稀缺。原因不是 React 难学，而是大型 React 项目的隐性知识（性能优化、架构分层、生态选型）集中在少数人手里。这是市场现象，与框架本身好坏无关，但直接影响团队的招聘成本和技术债务风险。

4. 生态更迭：重构成本被低估

状态库、路由库、数据请求库的"版本换代"节奏快，升级往往伴随 breaking changes。对长期维护的项目，这意味着持续的重构预算。Redux → Redux Toolkit、CRA → Vite 的迁移是近年最典型的两次。

5. 依赖体积：node_modules 与供应链风险

一个中型 React 项目的依赖树可达数千个包。体积影响构建和加载速度，供应链风险（依赖被投毒、维护者弃坑）则是安全团队的长期关注点。这与 React 本身无关，是 npm 生态的普遍问题，但在 React 项目中最常见。

社区给出的替代路径

这些方案各有适用场景，不是"取代 React"的统一答案：

  • Svelte / Solid：编译时优化，把框架开销转移到构建期，运行时更轻。适合对包体积和首屏性能敏感的项目。
  • Astro：岛屿架构，默认静态输出，交互部分按需加载。适合内容型站点。
  • 原生 JS + 轻量工具：对简单页面，避免框架抽象反而更可控。
  • WebAssembly：计算密集型场景（如数据分析、图像处理）直接下沉到 WASM，与前端框架正交。

结论

React 不会消失，但它的定位正在从"默认选项"变成"选项之一”。对开发者而言，了解这些痛点的边界条件（什么场景下成立、什么场景下不成立）比站队更有价值。选型建议回归两个问题：你的页面交互密度有多高？你的团队维护成本能承受多大？

注：本文为观点整理，未引用具体公司案例数据；文中提到的性能数字，应以各框架官方 benchmark 和自身项目实测为准。