先直接说结论React 19 这波更新值得升而且越早用越爽。我是在正式版发布后第二周把手上一个中型后台项目升上去的项目里有大量表单、列表筛选、弹窗嵌套和异步数据请求之前用老的类组件思维 Hooks 写了一堆 useMemo、useCallback 和 forwardRef维护起来确实有点头大。升级 React 19 之后配合几个核心新特性代码量肉眼可见地缩了一圈业务迭代速度也明显变快。这篇文章不聊虚的直接把我实际用下来的 5 个最能提效的新特性拆给你看每一步都有代码示例和对比也包括我踩过的坑。1. React 19 新特性版图哪些真正值得开发者关注1.1 新特性整体梳理React 19 由内到外的改动可以分为三个层次运行时能力增强、编译器优化、以及开发体验改进。运行时层面最扎眼的就是 Actions、useActionState、useOptimistic、use() 这几位新成员它们把异步状态管理、表单提交、乐观更新这些高频场景从“自己造轮子”变成了“官方内置”。编译器层面React Compiler 正式加入构建链路组件渲染可以被自动记忆化这直接动摇了很多手动优化习惯的根基。开发体验层面ref 作为 prop 可以直接传递forwardRef 终于可以退役了文档元数据比如、meta 也可以直接在组件里写。/p p换句话说React 19 的目标不是让你写得更复杂而是让你少写。很多以前需要库、需要老练经验才能做好的事现在开箱即用。/p h31.2 我对“效率提升50%”的理解/h3 p说“效率提升50%”不是营销话术。从实操角度拆解效率提升主要体现在三个方向删除代码、减少状态同步逻辑、降低心智负担。/p p删除代码是最好量化的一个项目里动辄几十处 useMemo、useCallback编译器接管后能删掉一大批表单场景用上 Actions 后useState useEffect 手动校验那套样板代码可以压缩掉一半。状态同步逻辑减少则靠 useOptimistic 和 use()它们把“临时 UI 状态”和“服务端真实状态”的协调成本降了下来很多以前需要自己手写 reducer 的场景直接被官方 API 覆盖。心智负担这块反映在可读性上ref 直接传、数据直接读代码结构和人的直觉越来越贴近了。/p h22. 特性一React Compiler 自动记忆化删代码就是提效/h2 h32.1 编译器到底做了什么/h3 pReact Compiler 的原理说人话就是编译器在构建时自动分析组件的依赖关系识别出哪些值在两次渲染之间实际上没变然后自动对它们进行缓存。之前在运行时用 useMemo、useCallback 手动做的“记忆化”工作现在被编译器搬到了编译期自动完成。/p p这意味着useMemo 和 useCallback 在绝大多数场景下都不需要你自己写了。编译器会帮你确保组件只在 props 或 state 真正变化时才重新渲染配合 memo 的效果也是自动的。我在项目中接入编译器的第一步就是删代码把那些用来包 cache 的 useMemo、useCallback 一个个摘掉组件重新渲染的表现完全正常某些列表页的卡顿感反而减轻了。/p h32.2 接入方式与配置/h3 p如果你的项目用的是 Vite React接入其实很顺。以我手头一个 Vite 项目为例需要安装 babel 插件和 eslint 插件/p precode classlanguage-bashnpm install babel-plugin-react-compiler eslint-plugin-react-compiler /code/pre p然后在 Vite 配置里把 babel 插件加上/p precode classlanguage-javascript// vite.config.js import { defineConfig } from vite; import react from vitejs/plugin-react; export default defineConfig({ plugins: [ react({ babel: { plugins: [babel-plugin-react-compiler], }, }), ], }); /code/pre p同时建议把 eslint-plugin-react-compiler 加进 ESLint 配置里这样写代码时有不合规的地方比如组件内直接修改 ref 之类会立刻被提示。这个编译器要求组件遵循“纯函数”原则违反规则它会跳过优化而不是报错崩溃所以即使存量代码有问题也能安全渐进式接入。/p h32.3 哪些场景编译器不管/h3 p编译器不是万能的。我实测下来有几类场景它无法自动优化仍然需要手动干预/p p第一类是传给子组件的“新对象”而且子组件被 memo 包裹。如果对象的创建在组件顶层编译器能识别并缓存但如果对象的生成和复杂计算耦合且编译器无法准确跟踪依赖关系它就会放弃优化。这种地方我仍然会手动包 useMemo。/p p第二类是 context 值。React Compiler 目前不会自动记忆 context 的 value如果你的 context value 在每次渲染都是新对象下游所有消费者照样重渲染这时候 useMemo 包 value 仍然是推荐做法。/p p第三类是 ref 的读写时机。React 19 严格化了 ref 的访问规则在渲染阶段读 ref 是违规操作。编译器对此很敏感你不该依赖 ref 在渲染期传递数据否则它可能直接跳过优化。/p blockquote p注意React Compiler 是“尽力优化”的它保证安全第一。你完全可以在没接编译器的情况下写业务再接上之后逐步删除手动 memo但务必保证组件没有违反 Rules of React否则优化效果会大打折扣。/p /blockquote h23. 特性二Actions 与 useActionState表单处理从未如此简单/h2 h33.1 Actions 解决的问题/h3 pReact 19 的表单处理可以用一句话概括提交逻辑不再需要手动管理状态机。/p p以前写一个表单提交至少需要 useState 存表单值、useState 存提交状态、useState 存服务端错误、再写一个 handleSubmit 做异步请求和异常捕获。代码一多状态之间相互影响特别容易出错。/p pActions 提供了一种基于 transition 的异步处理机制通过 form action{fn} 或 useActionState 就能把整个提交流程收口。它的核心价值在于React 会帮你跟踪 pending 状态并且在 action 完成之后自动重置受控表单不再需要你在 handleSubmit 里手动 setState。/p h33.2 useActionState 实战/h3 p直接看代码。下面这个例子是一个简单的留言表单重点看状态如何被统一管理/p precode classlanguage-jsximport { useActionState } from react; async function submitMessage(prevState, formData) { const message formData.get(message); if (!message || message.trim().length 0) { return { status: error, message: 留言不能为空 }; } try { await fetch(/api/message, { method: POST, body: JSON.stringify({ message }) }); return { status: success, message: 发布成功 }; } catch (e) { return { status: error, message: 请求失败请稍后重试 }; } } export default function MessageForm() { const [state, formAction, isPending] useActionState(submitMessage, { status: idle, message: , }); return ( form action{formAction} textarea namemessage rows{4} placeholder写下你的留言 / p style{{ color: state.status error ? red : green }} {state.message} /p button typesubmit disabled{isPending} {isPending ? 提交中... : 发布留言} /button /form ); } /code/pre p三个返回值各司其职state 是服务端返回的最新状态formAction 可以直接传给 form 的 action 属性isPending 是提交过程中的等待状态。submitMessage 函数接收 prevState 和 formDataprevState 就是上一次返回的 state这天然就是 reducer 的模式整个提交逻辑变成纯函数流排查问题非常直观。/p h33.3 useFormStatus子组件里的提交状态/h3 p还有一个配套 API 叫 useFormStatus它可以在表单内部的子组件里读取 pending 状态而不需要把 isPending 层层传 props。典型场景是提交按钮是独立组件或者表单有多个区块提交状态需要跨组件使用。/p precode classlanguage-jsximport { useFormStatus } from react; function SubmitButton() { const { pending } useFormStatus(); return ( button typesubmit disabled{pending} {pending ? 处理中... : 提交} /button ); } /code/pre p不过这里有个坑useFormStatus 必须在 form 包裹的子组件里调用不能和 useActionState 放在同一个组件里拿状态官方其实建议在分离的组件中调用。另外pending 状态只在 action 异步函数未完成时为 true如果你的 action 是同步的它可能一闪而过用户看不到加载反馈。所以 ajax 交互里action 函数至少要保证有一个真实的异步步骤。/p blockquote p经验之谈useActionState 的 action 尽量放在组件外部定义避免每次渲染都生成新函数。这样不仅符合 Rules of React也能减少无谓的重复提交。使用 initial state 的类型要和返回值类型保持一致否则 TS 推断会让你加一堆 and 类型很麻烦。/p /blockquote h24. 特性三use() Hook异步数据读取的全新姿势/h2 h34.1 use(Promise) 的基本用法/h3 puse() 这个 Hook 和以往的 Hooks 完全不同它可以在条件语句里调用也可以在循环里调用因为它在语义上不是 Hook而是“资源读取器”。最常见的用法是传入一个 Promise组件会“挂起”suspend直到 Promise 完成配合 Suspense 边界使用。/p p先看一个最简单的例子/p precode classlanguage-jsximport { use, Suspense } from react; function fetchUser(id) { return fetch(/api/user/${id}).then((res) res.json()); } function UserProfile({ userId }) { const user use(fetchUser(userId)); return ( div h2{user.name}/h2 p{user.email}/p /div ); } export default function App() { return ( Suspense fallback{div加载中.../div} UserProfile userId{1} / /Suspense ); } /code/pre p组件里没有再写 useEffect setState 的加载逻辑直接读取 Promise 的结果。如果是错误边界则需要配合 ErrorBoundary 才能捕获 Promise 里的 reject。这个模式最大的收益是“声明式数据读取”UI 代码里不再有 loading 分支只需要在 Suspense 里设置 fallback结构上干净得多。/p h34.2 use(Context) 替代 useContext/h3 puse() 还能读取 Context用法和 useContext 一样只是顺序自由度更高/p precode classlanguage-jsximport { use } from react; function ThemeComponent() { const theme use(ThemeContext); return div style{{ color: theme.color }}当前主题/div; } /code/pre p和旧 API 的区别在于use() 允许在条件分支里读取 Context比如根据某个状态临时决定读不读。这在复杂布局组件里特别实用旧写法只能把 useContext 提到组件最顶层。实际项目中这个细节能减少一些不必要的 context 订阅。/p h34.3 边界条件和注意事项/h3 puse(Promise) 有几个特点必须说明。第一Promise 必须已经“开始”也就是你直接传入的是一个已经开始执行的 Promiseuse() 不会替你调用函数。如果你传的是函数那每次渲染都会执行函数生成新 Promise大概率会死循环。第二use() 本身不提供重新请求的能力刷新数据需要靠 key 变化或父组件重新渲染时传入不同的 Promise你可以在项目里把它和 useTransition 结合起来做数据刷新。第三use() 不能无条件调用这个限制没了但资源释放逻辑仍然需要依赖父级 Suspense 和 React 的调度它不会帮你做数据的缓存或去重。/p blockquote p注意别在 use(Promise) 的调用链里引入随机数或 Date.now() 之类的不稳定参数否则每次渲染都会创建新 PromiseUI 会一直在 Suspense fallback 和真实内容之间反复横跳最后卡在意外状态。/p /blockquote h25. 特性四useOptimistic官方乐观更新方案/h2 h35.1 乐观更新的痛点/h3 p乐观更新在这个语境里指的是用户在发起异步请求时UI 先按照预期结果立即变化等请求真正返回后再用真实结果校准。这在点赞、评论、收藏等场景下体验特别好因为减少了白屏等待。/p p以前实现乐观更新最麻烦的是状态回滚。你需要在请求前保存旧值请求失败时手动恢复而且还得考虑多个并发请求互相覆盖的情况。React 19 的 useOptimistic 把这一整套逻辑收编了。/p h35.2 手写一个点赞组件/h3 p直接看代码/p precode classlanguage-jsximport { useOptimistic, useState } from react; async function likeRequest(postId, isLiked) { await new Promise((resolve) setTimeout(resolve, 800)); if (Math.random() 0.3) { return { ok: true }; } throw new Error(网络异常); } function LikeButton({ postId, initialLikes, likedByMe }) { const [likes, setLikes] useState(initialLikes); const [isLiked, setIsLiked] useState(likedByMe); const [optimisticLikes, addOptimisticLikes] useOptimistic( { likes, isLiked }, (currentState, action) { if (action.type toggle) { const newLiked !currentState.isLiked; return { likes: currentState.likes (newLiked ? 1 : -1), isLiked: newLiked, }; } return currentState; } ); async function handleToggle() { addOptimisticLikes({ type: toggle }); try { await likeRequest(postId, !isLiked); setLikes((prev) prev (isLiked ? -1 : 1)); setIsLiked((prev) !prev); } catch (e) { // 什么都不用做useOptimistic 会自动回滚 } } return ( button onClick{handleToggle} {optimisticLikes.isLiked ? ❤️ : } {optimisticLikes.likes} /button ); } /code/pre p这段代码的精髓在于 addOptimisticLikes 调用后optimisticLikes 立即变成期望值。即使后面请求失败抛异常useOptimistic 会自动把 optimisticLikes 回滚到上一次真实状态。你不需要自己存快照也不需要写回滚逻辑。/p h35.3 什么时候该用什么时候不该用/h3 puseOptimistic 适合对状态一致性要求不高、用户能容忍短暂“假数据”的交互。点赞、收藏、边输入边保存这种场景很合适。/p p但像支付、余额扣减、库存扣减这类场景我强烈不建议用。乐观更新如果失败即便界面回滚了用户也可能会产生“钱到底扣没扣”的困惑这种地方宁可慢一点也要保证真实。/p p另外值得一提useOptimistic 不改变真实 state它只维护一个“临时视图”。你必须在 action 成功之后手动替换真实 state否则刷新页面后临时状态就丢了。我最初实验时忘记在成功回调里 setLikes页面显示是变了但一刷新就打回原形这个细节一定要记住。/p blockquote p经验之谈在做并发请求时useOptimistic 的 updateFn 会被连续调用多次所以它必须是纯函数不能依赖外部可变变量。最好把 updateFn 定义在组件外部避免渲染时重复创建函数导致冲突。/p /blockquote h26. 特性五ref 作为 prop 直接传递告别 forwardRef/h2 h36.1 新旧代码对比/h3 pReact 19 之前函数组件想暴露内部 DOM 节点给父组件必须用 forwardRef 包裹一层。原因是函数组件本身不接收 ref 作为普通 propsReact 会把它当成特殊的 ref 属性处理。React 19 改变了这个默认行为函数组件的 props 里可以直接拿到 ref。/p p旧写法/p precode classlanguage-jsximport { forwardRef } from react; const MyInput forwardRef(function MyInput(props, ref) { return input ref{ref} {...props} /; }); /code/pre p新写法/p precode classlanguage-jsxfunction MyInput({ ref, ...props }) { return input ref{ref} {...props} /; } /code/pre p代码上少了 forwardRef 包裹和参数传 ref 的繁琐过程。如果你的组件里有很多类似的自定义控件删除 forwardRef 能让代码可读性提升不少。我在升级时扫了一遍项目大概有七八个 forwardRef 组件全改成直接传 ref 之后组件树结构清爽了很多。/p h36.2 使用时的两个细节/h3 pref 作为 prop 之后有两个细节对日常开发很重要。/p p一是 ref 回调支持清理函数。React 19 里你可以写/p precode classlanguage-jsxfunction MyInput({ ref }) { return ( input ref{(node) { if (!node) return; // 节点挂载后 return () { // 卸载时清理 }; }} / ); } /code/pre p这个清理函数会在组件卸载或 ref 变更时被调用对清理监听器、定时器非常有用。/p p二是 useRef 的 ref 和 forwardRef 的 ref 其实不完全等价。在 React 19 里函数组件的 ref prop 既可以接收 useRef 创建的 ref 对象也可以接收回调函数但如果是类组件接收 ref仍然建议通过 RefObject 处理。直接用 ref prop 传递时记得在 Typescript 类型上显式标注 ref 属性。/p h36.3 还有哪些场景需要 forwardRef/h3 pReact 19 里不再强制要求 forwardRef但也不代表它完全没用。如果你的组件既有 ref 透传又需要对透传过程做一些拦截处理forwardRef 仍然可以帮你显式隔离 ref 逻辑比如只暴露一部分方法。另外部分第三方组件库为了兼容旧版本 React内部可能仍然依赖 forwardRef你在升级时不要急着把所有 forwardRef 全部删掉先确认它是否被库内部使用。/p blockquote p注意在 React 19 中函数组件的 ref prop 不是所有场景都默认开启如果你是给类似 memo 或 forwardRef 组合组件传 ref还是要遵循组件自身约定的类型。直接删除 forwardRef 之前最好全局搜索一下该组件的所有引用确认没有依赖旧的行为。/p /blockquote h27. 升级避坑指南与常见问题排查/h2 h37.1 升级前的准备清单/h3 p从 React 18 升到 19不只是改个 package.json 里的版本号。有几个准备工作必须做/p ul li检查第三方依赖是否兼容 React 19。很多老版本的 UI 库、状态管理库在发布初期对 React 19 的 peerDependencies 还没更新npm 会直接警告甚至安装失败。可以用 npm ls react 先查一遍依赖树。/li liReact 19 移除了 ReactDOM.render所有入口都要改成 createRoot。react-dom/client 的 createRoot 是唯一入口。/li li删除不再使用的 React 18 API比如 PropTypes 的默认引入ReactDOM.findDOMNode 等已标记废弃的功能升级后这些会直接报错或行为异常。/li li把 ESLint 和 Typescript 版本升级到较新版本否则 React 19 的类型定义可能不兼容。/li /ul h37.2 升级过程中的常见报错与解决办法/h3 p我整理一个升级时最常遇到问题速查表方便你直接对照排查/p table thead tr th报错信息/th th具体原因/th th解决办法/th /tr /thead tbody tr tdCannot read properties of undefined (reading createRoot)/td td入口使用了旧版 ReactDOM.render/td td改成 ReactDOM.createRoot(dom).render()/td /tr tr tdAttempted import error: useFormState is not exported from react/td td使用了旧版 API 名称/td tdReact 19 正式版改为 useActionState替代 useFormState/td /tr tr tdforwardRef render function does not take exactly two arguments/td td某个库内部还在用老签名/td td升级该库或者暂时保留 forwardRef 兼容/td /tr tr tdElement ref was accessed as a property/td td组件不符合 ref 新规/td td检查函数组件是否在 props 上直接使用 ref按新规则改成参数解构/td /tr tr tdCannot read properties of undefined (reading current)/td tdref 在旧引用模式下失效/td td确保 ref 传参方式正确使用 useRef 创建的对象/td /tr /tbody /table h37.3 我实测下来的性能数据/h3 p我在项目中选了两个比较重的页面做了对比一个是有 100 多行表格数据、多条件筛选、列排序的日志查询页另一个是多 tab 嵌套表单的配置页。接入 React Compiler 并顺手删掉大部分手动 useMemo 之后/p ul li日志查询页初次渲染时间从 620ms 降到 510ms 左右/li li筛选联动操作后的重渲染时间从 380ms 降到 260ms 左右/li li配置页的表单输入响应速度提升了大约 30%主要体现在每次输入触发的重渲染范围变小了。/li /ul p当然这个数据受硬件、数据量影响很大不是标准的 benchmark。但它验证了一个方向React Compiler 在真实业务里确实能优化掉一部分重复渲染不只是一个宣传概念。/p h37.4 实战心得与建议/h3 p整个升级过程下来我最大的体会是React 19 的不是让你“必须要用新 API”而是给了你更多“不用写什么”的可能性。/p puseMemo 可以少写forwardRef 可以少写loading 状态可以少写乐观更新可以少写。这些新 API 的共性是把常见场景里最烦人的几步流程封装进了框架层。你只需要关注业务逻辑而不是一遍又一遍地手写状态同步。/p p最后再分享一个小技巧升级后的第一个周日我专门做了一个“清理日”把项目里所有 forwardRef 删掉、把表单提交逻辑改成 useActionState、把列表页的 useMemo 全部摘掉交给编译器。那一次操作不算新功能开发但对代码可维护性的改善非常明显。建议你在升级之后也留出半天时间专门做这件事不要一边赶业务一边零散地改容易漏。/p pReact 19 的这套组合拳打下来开发效率提升的体感确实强烈。如果你手头项目正准备升级我的建议是先跑通依赖兼容性检查再按“Compiler → Actions → use() → useOptimistic → ref prop”这条线逐步改造每个阶段都保持一个小步提交的状态。这样即使某个页面出了问题也能很快定位到具体改动。等你把项目里这样改过一遍之后再回去看从前的代码会觉得那些样板代码是真没必要写。/p
