React 19 潜在性能问题与社区反应
背景与影响范围
React 仍是全球最流行的前端框架，为 Netflix、Airbnb、Discord 及 Meta 旗下产品提供用户界面，其运行时性能影响着海量互联网流量。今年宣布的 React 19 引入了诸多新特性，但一项未被广泛注意的变更可能显著降低依赖特定数据获取模式的网站性能。
核心变更：Suspense 边界内渲染机制的改动
该变更源于一个 GitHub Pull Request (#26380)，主要调整了同一 Suspense 边界内兄弟组件的渲染行为：
- React 18 行为：当边界内有多个组件时，即使第一个组件触发挂起，React 仍会尝试渲染所有兄弟组件。若组件内包含数据获取或懒加载，这些操作会并行启动。
- React 19 变更后行为：一旦首个组件挂起，渲染立即停止（即“中止”），后续兄弟组件的数据获取或懒加载不会启动，直到前一组件完成。这导致原先并行的操作变为顺序执行（瀑布流），增加整体加载时间。
技术示例与影响
代码示例展示了三个同级 Suspense 边界内的数据获取组件：
- 在 React 18 中，三个数据请求几乎同时发起（并行）。
- 在 React 19 中，请求顺序执行，形成瀑布流，总耗时延长。
此变更不仅影响基于第三方库（如 TanStack Query）的客户端数据获取模式，也影响长期官方支持的 React.lazy 代码分割模式，波及范围较广。
变更理由与开发者体验权衡
React 团队解释此变更有两方面考量：
- 性能优化：原机制尝试渲染所有兄弟组件后再显示 fallback，延迟了加载指示器的出现。
- 架构理念对齐：与团队倡导的 “渲染时获取” 理想模式一致——即数据获取应尽早发起（如在组件外部），而非在渲染时触发。
然而，理想模式要求组件与其数据需求分离（即数据获取逻辑提升到组件外），这会损害 开发者体验，难以实现组件与数据的就近维护（colocation）。社区指出，在不依赖编译器（如 Relay）的情况下，兼顾最佳性能与开发便利性非常困难。
社区反应与后续
该变更引发开发者社区广泛关注与批评，核心维护者（如 TanStack Query 维护者 TkDodo）和社区成员通过社交媒体指出其对现有代码的破坏性影响。鉴于强烈的反对声音，React 团队最终暂时搁置了这一变更。
总结
此次事件凸显了 React 核心团队的技术愿景（侧重渲染优化与架构理念）与广大开发者实际使用模式及依赖之间的张力。React 19 的此项变更虽出于性能考虑，但可能破坏现有并行数据获取模式，影响开发范式。社区反馈最终促使团队暂停推进，也反映出大型开源项目中技术决策与社区协同的挑战。