React 曾经代表着前端开发的一次范式革命 —— 组件化、单向数据流、虚拟 DOM，这些概念在 2013 年颠覆了 jQuery 时代混乱的 DOM 操作。然而十多年过去，当 "React 已成为一把锤子，让一切看起来像钉子" 的批评声在开发者社区此起彼伏时，我们需要冷静审视：这个生态系统的隐性成本究竟在哪里？为何越来越多的团队在 "喜欢 React" 和 "忍受 React" 之间摇摆？
Hooks：优雅表象下的心智模型债务
React 16.8 引入的 Hooks 曾被赞誉为 "让函数组件拥有状态" 的神来之笔，但多年实践暴露出一个残酷事实：Hooks 的正确使用门槛被严重低估。
依赖数组的陷阱是首要问题。useEffect 的第二个参数 —— 那个看似简单的数组 —— 实际上要求开发者对组件渲染周期、闭包捕获、引用相等性有深入理解。一个遗漏的依赖项可能导致陈旧的闭包值，而过度添加依赖又可能引发无限渲染循环。社区中充斥着 "为什么我的 effect 不触发" 或 "为什么我的组件无限重渲染" 的提问，这些问题的根源往往不是代码逻辑错误，而是对 Hooks 心智模型的误解。
更隐蔽的是性能优化 Hooks 的误用。useMemo 和 useCallback 本应是性能救星，但错误的依赖配置或不必要的包裹反而增加了内存开销和比较成本。正如社区批评所指出的："Hooks 难以正确使用，更难以高性能方式使用。" 这种复杂性并非 "技能问题"—— 即使是经验丰富的开发者，在代码审查中也经常需要花费大量精力追踪依赖链条。
服务端组件：复杂度转移而非消除
React Server Components (RSC) 被定位为解决 "水合问题" 的终极方案，但它引入的新复杂度同样不容忽视。
传统的 SSR 模式存在明显的重复计算：服务器端用 JavaScript 生成 HTML，客户端接收后又要下载并执行同样的 JavaScript 来 "水合" 页面。RSC 试图通过允许组件仅在服务端运行来解决这个问题，但代价是引入了 "服务器边界" 的新概念 —— 开发者现在需要思考哪些代码可以访问浏览器 API，哪些只能在服务端执行。
这种心智负担是真实存在的。一个典型的 RSC 项目需要处理：服务端组件与客户端组件的显式标记、数据获取时序的重新设计、第三方库对服务端环境的兼容性检查。2025 年底披露的 CVE-2025-55182 漏洞（CVSS 10.0）更是暴露了 RSC 架构在安全边界上的脆弱性 —— 服务端代码执行权限的失控可能导致未授权远程代码执行。
生态系统锁定：从框架到平台的陷阱
React 本身只是一个视图层库，但围绕它的生态系统已形成强大的网络效应锁定。
Next.js 作为 React 生态的 "默认选择"，其 15.1+ 版本被批评者指出 "在 Vercel 之外几乎不可用"。这并非技术限制，而是架构决策的结果：特定的缓存策略、边缘函数支持、图像优化服务 —— 这些功能在非 Vercel 环境中要么缺失，要么需要复杂的自行实现。当团队意识到迁移成本时，往往已经深陷其中。
这种锁定效应在技术决策层面表现为 "React 默认主义"。新项目启动时，讨论往往从 "让我们用 React，大家都熟悉" 开始，而非 "根据约束条件选择最适合的工具"。网络效应取代了技术适配，形成了自我强化的循环。结果是：React 开发者数量庞大，但真正理解深层模式的熟练开发者却稀缺且昂贵 —— 多位 CTO 报告称，资深工程师正因日益增长的复杂度而选择离开。
性能与维护的隐性成本
"JS 重度方案与长期性能目标不兼容"—— 这一论断在大型项目中得到反复验证。任何规模可观的 JS 密集型项目都会面临一个规律：初始性能尚可，但随着功能迭代，JavaScript 包体积持续增长，交互响应时间逐渐恶化。
维护成本同样被低估。React 生态的快速发展意味着知识半衰期极短。正如一位开发者所言："你会以为离开三年后回来仍能继续工作 —— 在其他技术栈可能如此，但在 React 生态，这种想法太天真了。" 从 Class 组件到 Hooks，从 Redux 到 React Query，从 CRA 到 Next.js App Router—— 每一次范式迁移都要求团队重新学习最佳实践。
可行的缓解策略
面对这些挑战，团队可以采取以下务实的缓解措施：
1. 技术选型前置约束分析 在决定使用 React 之前，明确列出项目约束：目标用户的网络环境、交互复杂度、团队规模、长期维护周期。对于内容为主的站点，考虑 Astro、Eleventy 等静态站点生成器；对于高度交互应用，评估 Solid、Svelte 等编译时优化框架。
2. 渐进式采用策略 如果必须使用 React，考虑 "岛屿架构"—— 核心页面使用轻量级方案，仅在必要交互区域嵌入 React 组件。这种方式可以显著减少初始 JavaScript 负载。
3. 建立内部 Hooks 规范 制定团队级别的 Hooks 使用规范：强制使用 ESLint 插件检查依赖数组、禁止在 useEffect 中执行复杂异步逻辑、建立自定义 Hooks 的审查清单。将隐性知识显性化。
4. 监控真实性能指标 不要只关注构建成功率和测试通过率。建立 Core Web Vitals 的持续监控，特别是 LCP（最大内容绘制）和 INP（交互到下一帧绘制），这些指标直接反映用户体验。
5. 保持技术栈的退出通道 避免过度依赖特定平台的专有功能。如果选择 Next.js，确保关键业务逻辑不深度绑定 Vercel 的特定实现，为未来的迁移保留可能性。
结语
React 并非一无是处 —— 它在特定场景下仍是合理选择。但 "合理" 与 "默认" 之间存在巨大鸿沟。当技术选型被网络效应而非技术适配驱动时，开发者体验的代价最终会通过代码质量、维护成本和用户性能反馈回来。
作为工程师，我们的职责是在 "大家都用" 和 "应该用" 之间保持清醒的判断。React 生态的批评声浪提醒我们：没有永恒正确的技术，只有永恒正确的工程思维 —— 根据约束选择工具，而非让工具定义约束。
参考来源
- JSX.lol - React 批评文章聚合
- React 官方博客：RSC 安全漏洞披露
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。