12.18 React 的未来方向

一句话：React 的演进有五条主线——「Compiler（编译期优化）、RSC（服务端组件）、Actions（数据变更的统一抽象）、并发与调度（Activity/View Transitions）、多平台运行时（RN 新架构）」，而它们共同的趋势是「让开发者「少写样板、少管性能」，把「协调与优化」交给框架与编译器」。

一、五条主线（⭐ 一条比一条「结构性」）

⭐⭐⭐ 主线 ①【Compiler：把所有「手动 memo」交给编译器】

   现状（⭐ 见 4.15）：`babel-plugin-react-compiler` 已经在生产可用——
     ⭐ 「自动识别「哪些计算依赖响应式输入」」+ 「自动插入 `useMemoCache`」
   趋势：
     · ⭐ **「手动 `useMemo`/`useCallback` 会越来越少见」**
       （⚠️ 但「Context 的 value 稳定」「结构性优化」还得自己写）
     · ⭐ 「lint 会拦住「不纯的组件」（⭐ 把「渲染必须纯」变成「可执行的检查」）」
     · ⭐ **「编译期的知识」会越来越多的进入 React**（⭐ 而不只是运行时的调度）
   ⭐ 对开发者的影响：
     · ⭐ 「性能调优的门槛降低」（⭐ 但「理解渲染机制」依然必要 —— 否则「你不知道「编译器的边界在哪」」）
     · ⚠️ 「写代码要「更纯」」（⭐ 「渲染中读 ref/setState」这类会被拒绝编译）

⭐⭐⭐ 主线 ②【RSC：把「组件」这个概念一分为二】

   现状（⭐ 见 4.12）：Server Components 已经在 Next.js 稳定可用——
     · ⭐ 「服务端组件」：能「直接读数据库/文件」、**不进客户端 bundle**
     · ⭐ 「客户端组件」：`'use client'` 明确标记的交互组件
   趋势：
     · ⭐ **「默认在服务端」（⭐ 这是「心智模型的转变」）**——
       「客户端组件变成「需要显式声明的特例」」
     · ⭐ **「`'use client'` 的边界」会成为「库作者的核心约束」**（⭐ 一个库要「同时支持两种组件」）
     · ⭐ **「数据获取「上移到服务端」」**——
       「客户端 `useEffect` 拉数据」的用法会「越来越少」（⭐ 见 8.1 的「你可能不需要 Effect」）
     · ⚠️ 「与「现有生态」的磨合」还在进行（⭐ 大量库还在「适配 RSC」）
   ⭐ 对开发者的影响：
     · ⭐ **「要理解「哪部分代码跑在哪」」**（⭐ 否则「把服务端的东西「不小心带到客户端」」）
     · ⭐ 「bundle 体积的优化「变得更结构性问题」」（⭐ 「服务端组件不占客户端体积」）

⭐⭐⭐ 主线 ③【Actions：把「数据变更」变成一等公民】

   现状（⭐ 见 9.10 与 2.15）：Server Actions + `useActionState` + `useFormStatus` + `useOptimistic`
     · ⭐ 「表单提交」不再需要「手写 fetch + loading + 错误处理」
     · ⭐ 「`revalidateTag` 内建与缓存体系的联动」
   趋势：
     · ⭐ **「Mutation 的抽象会继续统一」**——
       「表单」「乐观更新」「重新验证」被「串成一条流水线」
     · ⭐ **「渐进增强」被重视**（⭐ 「JS 未加载也能提交」—— 这是「Web 本质」的回归）
     · ⚠️ 「安全」的责任仍然在开发者（⭐ 「Server Action 是一个公开 POST 端点」，见 9.10）
   ⭐ 对开发者的影响：
     · ⭐ **「要习惯「服务端能做的就放服务端」」**
     · ⭐ **「安全与校验的意识更重要」**（⭐ 「写得更省」不等于「更安全」）

⭐⭐⭐ 主线 ④【并发与调度：让「优先级」变得「可编程」】

   现状（⭐ 见 4.16/4.17）：`startTransition` / `useDeferredValue` / Suspense / Lane 模型
   值得关注的具体动向：
     · ⭐ **`<Activity>`（原 Offscreen）**——「隐藏但不卸载」（⭐ 保留 state/DOM，
       清理 effect）→ 「切 Tab 保留输入/滚动位置」（见 4.13）
     · ⭐ **View Transitions**（⭐ 「浏览器原生的页面切换动画」，见 6.13）
       —— ⭐ 它可能「把「页面过渡」变成「框架与浏览器的标准协作」
     · ⭐ **Owner Stacks（更清晰的错误栈）**——⚠️ 「现在的错误栈「看不出「是哪个组件渲染的」」，
       它会「把「组件的调用链」带上」
     · ⭐ **「更细的调度原语」**（⭐ 如「让「某个更新」明确为「不阻塞输入」）
   趋势：
     · ⭐ **「并发不是「高级特性」而是「默认行为」」**（⭐ 「同步渲染」会越来越边缘）
     · ⭐ **「用户可感知的「响应性」成为一等目标」**（⭐ 即 INP 导向的框架设计）

⭐⭐⭐ 主线 ⑤【多平台运行时：React 不再只是「Web 框架」】

   现状（⭐ 见 10.15）：RN 的新架构（JSI/Fabric/TurboModules）已经在推进
   趋势：
     · ⭐ **「同一套心智模型驱动多端」**（⭐ Web / Native / Canvas / 文档 / 测试）
     · ⭐ **「服务端组件与 Native 的结合」**（⭐ 想象空间：服务端算 + 原生渲染）
     · ⚠️ 「但「多平台」的复杂度不会消失」（⭐ 它「从「框架层」挪到了「业务层」」）
   ⭐ 对开发者的影响：
     · ⭐ **「React 的「通用能力」（组件/状态/Hooks/并发）会「更值钱」」**
     · ⚠️ 「平台特有的知识（DOM/CSS/原生）**依然不可替代**」

二、对开发者：什么更值钱，什么会过时

⭐⭐⭐ 一条「不变的底层能力」（⭐ 无论框架怎么变）：

   ⭐ 「**把「不确定的需求」拆成「可验证的决策」**」——
     这就是「场景设计题」（12.16）与「选型题」（12.17）考的东西，
     也是「框架会变，但「工程判断力」不会过时」的原因。
   ⭐ 具体到技术：「**渲染机制、数据流、缓存与一致性、性能量化、可观测性、安全边界**」
     —— 这六件事「任何前端框架都要面对」。

三、谨慎：哪些是「确定的」，哪些「不确定」

⭐⭐⭐ 「确定的方向」（⭐ 已经落地或在明确推进）：
   ✅ 「Compiler 会普及」（⭐ 生产可用 + 收益明确）
   ✅ 「RSC 会成为「框架级标配」（⭐ Next.js 已在用，其他框架在跟进）」
   ✅ 「并发与 Suspense 会成为「默认」（⭐ 而不是「高级特性」）
   ✅ 「Actions 与「数据变更的抽象」会继续统一」
   ✅ 「INP/响应性会成为「框架设计的核心指标」」

⭐⭐⭐ 「不确定的」（⭐ 诚实地说「不知道」比「装作知道」加分）：
   ⚠️ 「RSC 与「现有生态的磨合要多长时间」（⭐ 大量库的适配仍在进行）
   ⚠️ 「Compiler 会不会「引入新的心智负担」（⭐ 「为什么要「按它的方式写」」）
   ⚠️ 「Signal 式的细粒度响应式会不会「以某种形式回到 React」」
     （⭐ 现在是「Compiler + `useSyncExternalStore`」，见 12.13）
   ⚠️ 「服务端/客户端边界的「最佳实践」还未稳定」
   ⚠️ 「Web Components / 微前端 / 边缘渲染 的长期地位」
   ⭐ 而且：⚠️ 「「更省心的框架」也可能「把复杂度转移到「其他地方」」」
     （⭐ 如「RSC 的调试/部署复杂度」「Server Action 的安全责任」）

⭐ 一句话：「**趋势可以判断，时间点不能预测**」——
   所以「不要把「押注未来」当成「现在就该做的事」」（⭐ 按「约束」选型，见 12.17）。

⭐⭐⭐ 「对你的项目」该怎么应对（⭐ 三条务实建议）：

   ① ⭐ **「跟着「稳定的方向」走，不追「实验特性」」**
      · ✅ 「该做」：让「渲染更纯」（⭐ 为 Compiler 做准备）、
        「把数据获取分层」（⭐ 为 RSC 做准备）、
        「用 Actions/useOptimistic 做表单」（⭐ 已经稳定）
      · ⚠️ 「先别做」：「全站押注「还在变化的最佳实践」」
   ② ⭐ **「保持「可迁移」」**（⭐ 见 12.17 的「退出策略」）
      · ⭐ 「数据层封装在一层」「业务逻辑与框架解耦（service 层）」（⭐ 见 9.10）
      · ⭐ 这样「框架升级/替换」的成本「可控」
   ③ ⭐ **「投资「不会过时的能力」」**
      · 「渲染机制、缓存与一致性、性能量化、可观测性、安全、无障碍」
      ⭐ 「这些在任何框架下都要面对」

四、面试延伸：怎么答「趋势题」

⭐⭐⭐ 「你怎么看 React 的未来？」（⭐ 四段答法）

   ① 【先给「五条主线」（⭐ 结构清晰）】
      「我会看成五条主线：
        **Compiler（编译期优化）、RSC（服务端组件）、Actions（数据变更抽象）、
          并发与调度（Activity/View Transitions/Owner Stacks）、多平台运行时（RN 新架构）**。」

   ② 【说「它们共同的趋势」（⭐ 一句话点出本质）】
      ⭐ 「它们的共同方向是「**把「协调与优化」从开发者手上拿走**」——
        所以「样板代码」和「微优化」会变少，而「**架构判断**」与「**安全/一致性**」会变得更贵。」

   ③ 【分清「确定」与「不确定」（⭐ 展示判断力）】
      ⭐ 「比较确定的：**Compiler 会普及、RSC 会成为框架级标配、并发成为默认、
        响应性（INP）成为核心指标**。
        ⚠️ 不太确定的：**RSC 与生态磨合的时长、服务端/客户端边界的稳定实践、
        Compiler 是否引入新的心智负担**。
        ⭐ 我的态度是「**趋势可以判断，时间点不能预测**」。」

   ④ 【落到「我的项目怎么做」（⭐ 最加分）】
      ⭐ 「所以我会：
        · **跟着稳定方向走**（让渲染更纯、数据获取分层、用已稳定的 Actions）
        · **保持可迁移**（数据层/业务逻辑与框架解耦）
        · **投资不会过时的能力**（渲染机制、缓存一致性、性能量化、可观测、安全、无障碍）」。

⭐ 三个「不要」：

   ❌ 「把「新特性」当成「必须现在用」」（⭐ 按「约束」决定，见 12.17）
   ❌ 「预测「具体时间点」」（⭐ 「明年 RSC 就会……」—— ⚠️ 不可靠）
   ❌ 「只讲「新 API 名称」不讲「它改变了什么心智模型」」
      （⭐ 如「RSC 改变的是「哪部分代码跑在哪」；Actions 改变的是「变更的连接方式」」）

五、一句话速记

React 的演进有五条主线：① Compiler（⭐ 编译期优化——「手写 memo 会越来越少」，但「理解渲染机制」依然必要，且「代码要更纯」）；② RSC（⭐ 把组件一分为二——「默认在服务端」是心智转变，'use client' 的边界成为库作者的核心约束，数据获取上移服务端）；③ Actions（⭐ 数据变更成为一等公民——表单/乐观更新/重新验证串成流水线，重视「渐进增强」，⚠️ **但安全责任仍在开发者）；④ 并发与调度（⭐ 让优先级可编程——<Activity>、View Transitions、Owner Stacks、更细的调度原语，「并发从高级特性变成默认」，「响应性（INP）成为框架设计的核心指标」）；⑤ 多平台运行时（⭐ RN 新架构 + 「同一心智模型驱动多端」）；⭐ **共同趋势是「把协调与优化从开发者手上拿走」→ 样板与微优化贬值，而「架构判断」与「安全/一致性」增值；⭐ 会贬值的：手写 memo 的肌肉记忆、Effect 里拉数据、微优化、兼容技巧、纯 API 记忆；⭐ 会增值的：理解「为什么需要 memo/编译器边界」、数据获取分层、结构优化、性能量化、设计 API 的能力、⭐ **安全与校验意识、⭐ 「把不可靠的东西做可靠」的能力（缓存失效/并发/离线/一致性）；⭐ 确定的：Compiler 普及 / RSC 成为标配 / 并发成为默认 / INP 导向；⚠️ 不确定的：RSC 与生态磨合时长 / 服务端客户端边界的稳定实践 / Compiler 是否引入新心智负担 —— ⭐ 「趋势可以判断，时间点不能预测」；⭐ 务实三条：跟着稳定方向走（让渲染更纯、数据获取分层、用已稳定的 Actions）→ 保持可迁移（数据层与业务逻辑解耦）→ 投资不会过时的能力（渲染机制、缓存一致性、性能量化、可观测性、安全、无障碍）。