刘文柱

# react各个版本变化（17 / 18 / 19）

# 为什么要按版本学习 React

React 17、18、19 不是“每次多几个 API”这么简单，背后是三次架构重心变化：

  • React 17：为升级铺路（兼容层重构，减少破坏性）
  • React 18：并发渲染落地（调度模型升级）
  • React 19：把并发能力产品化（表单、异步、资源加载体验升级）

如果只看语法，会觉得变化不大；如果看渲染模型和工程影响，差异非常大。

# React 17：无“新功能”的关键版本

官方当时强调 React 17 是一个“no new features”的版本，但它做了很多底层重构，目的是让未来版本更容易渐进升级。

# 1）事件委托从 document 下沉到根容器

旧版本主要把事件代理挂在 document；React 17 改成挂在 React 根节点。

# 影响

  • 多个 React 版本共存更安全（微前端、分步升级场景）
  • 与非 React 代码混用时事件冲突更少

# 2）移除事件池（SyntheticEvent pooling）

以前事件对象会被复用，异步里访问经常踩坑（需要 event.persist()）。
React 17 取消事件池后，事件对象使用更直觉。

# 影响

  • 降低心智负担
  • 老代码里 persist 大多不再必要

# 3）为渐进升级做兼容改造

React 17 大量工作在“升级体验”层：

  • 让 17 -> 18 的迁移可控
  • 让大型应用分区升级可行

# 核心结论

React 17 是“升级桥梁版本”，不是“功能爆发版本”。

# React 18：并发渲染时代

React 18 的关键字是 Concurrent Rendering（并发渲染能力）。
注意：不是说所有更新都并发，而是 React 拥有了可中断、可恢复、可分优先级的调度能力。

# 1）新的根 API：createRoot / hydrateRoot

import { createRoot } from "react-dom/client";
const root = createRoot(document.getElementById("root"));
root.render(<App />);
1
2
3

# 影响

  • 启用新渲染器能力的入口
  • 旧 ReactDOM.render 进入历史兼容路径

# 2）自动批处理（Automatic Batching）扩大范围

React 18 之前，批处理主要发生在 React 事件中；18 开始，Promise、setTimeout、原生事件等异步上下文也可自动批处理。

# 影响

  • 减少不必要重渲染
  • 状态更新表现更一致

# 3）Transition 模型

  • startTransition
  • useTransition
  • useDeferredValue

把更新分成“紧急更新”（输入响应）和“可延迟更新”（列表计算、复杂渲染）。

# 影响

  • 输入响应更丝滑
  • 大列表/重计算页面卡顿显著下降

# 4）StrictMode 在开发环境更“严格”

React 18 开发模式会故意触发一些额外执行（如 effect mount/unmount 再执行），用于暴露副作用不安全代码。

# 影响

  • 许多项目升级时误以为“React 重复渲染有 bug”
  • 本质是帮助你发现副作用不幂等问题

# 5）SSR 能力升级（Streaming + Suspense）

React 18 让服务端渲染更贴近“边请求边返回”，与 Suspense 协同更好。

# 影响

  • 首屏可更快输出
  • 大型 SSR 应用用户体验更好

# 6）useId

用于服务端与客户端一致的唯一 ID，解决 hydration 下 id 不一致问题。

# React 19：并发能力走向“默认工作流”

React 19 的重点是把之前偏底层的能力变成高层开发体验，尤其是表单、异步交互、资源加载。

# 1）Actions（动作式提交）与表单协同

React 19 强化了“以 action 驱动异步提交”的模式，让表单提交流程和 pending/error/success 状态管理更统一。

相关能力常与以下 Hooks 配合：

  • useActionState
  • useFormStatus
  • useOptimistic

# 影响

  • 表单“提交中/失败回滚/乐观更新”实现更自然
  • 减少手写样板状态机

# 2）useOptimistic

用于乐观更新：先让 UI 立即反馈，再在请求完成后确认或回滚。

# 影响

  • 评论、点赞、任务状态切换等交互体验显著提升

# 3）use（读取 Promise/Context）

React 19 进一步推动“在渲染阶段消费异步结果”的模式（常与 Suspense 搭配）。

# 影响

  • 异步读取模型更统一
  • 与 Server Components / 流式渲染生态联动更紧

# 4）文档元信息与资源加载能力增强

React 19 对 <title>、<meta>、样式表和脚本资源加载等场景支持更完善，减少框架层外部胶水代码。

# 影响

  • SSR/全栈框架里的 head 管理更顺滑
  • 资源优先级控制更精细

# 5）ref 使用体验演进

React 19 对 ref 传递与函数组件协作的体验更现代化，整体方向是减少历史包袱 API 的心智成本（如减少对 forwardRef 的依赖场景）。

# 17 -> 18 -> 19 的主线对比

# 架构目标

  • 17：升级平滑、兼容重构
  • 18：并发调度能力落地
  • 19：并发能力上移到业务 API

# 开发者体感

  • 17：代码几乎不变，但升级基础更稳
  • 18：需要理解并发与 StrictMode 新行为
  • 19：表单与异步交互写法明显升级

# 工程价值

  • 17：降低大项目迁移风险
  • 18：性能与响应性提升
  • 19：减少业务样板代码，提升交互质量

# 迁移建议（实战）

# 从 17 升 18

  1. 先替换根 API（createRoot）
  2. 全面检查副作用代码是否幂等（特别是 StrictMode 下）
  3. 对卡顿场景引入 startTransition/useDeferredValue

# 从 18 升 19

  1. 优先改造表单与提交链路（Actions + 状态 Hook）
  2. 在高频交互点引入 useOptimistic
  3. 评估已有资源加载/head 管理方案是否可简化

# 升级常见误区

  • 误区 1：把并发理解成“多线程”
  • 误区 2：把 StrictMode 二次执行当线上 bug
  • 误区 3：只升级版本号，不升级渲染心智模型

# 小结

深入看 React 版本变化，核心不在 API 数量，而在这条演进线：
兼容升级（17） -> 调度升级（18） -> 交互模型升级（19）。
真正吃到收益的团队，都是在升级时顺便升级了工程思维，而不只是改了 import。

react18并发调度源码主线 →