最近几个月React 社区讨论最凶的话题之一就是 React 19 新特性里反复提到的“告别 useEffect 的时代”。作为从 React 16 一路用到现在的老开发我第一反应是“又开始造概念了”但真正把 React 19 的新 API 在项目里跑了一遍之后我必须承认这次不是营销话术而是很多你以前不得不写 useEffect 的场景确实有了更优雅、更不容易出 bug 的替代方案。这篇文章我打算按实际项目的使用顺序来拆解先说 React 19 到底在“解决什么问题”再逐个掰开 useOptimistic、Actions、useActionState、use()、ref 作为 props 这些新特性重点讲清楚“新写法为什么能替代 useEffect”“老写法到底哪里有坑”最后附上我在迁移过程中踩到的坑和排查经验。通篇采用真实代码对比和实操建议不想看你直接抄作业也行。1. React 19 的“告别 useEffect”到底是怎么回事1.1 React 19 带来了哪些核心变化很多人一听“React 19”第一反应是“又一个版本号更新”觉得无非是性能优化、少量 API 调整。但这一版的改动幅度比我预想中大得多。它主要有几个大招Actions异步动作的统一解决方案、useOptimistic乐观更新、useActionState表单状态管理、use()在渲染中读取 Promise 或 Context、ref 作为 props 直接传递、ref cleanup 函数以及配套的 React Compiler。这些特性单独看各自解决一块问题但串起来你会发现一个共同点它们都在替你管理“异步状态切换”这件事。以前这些逻辑分散在 useEffect useState 手动 loading 标记里现在被统一收敛到了框架层。所以“告别 useEffect 的时代”这个说法本质上是在说React 的官方范式从“副作用驱动”转向了“状态驱动”。对前端开发者来说这等于以前你手动做的很多“脏活”——监听某个状态变化、发起请求、再更新另一个状态、处理竞态、清理副作用——现在有了更声明式的写法。它不是让你的代码变少那么简单是让状态和 UI 之间的因果链路变得更直接、更好推理。1.2 别误解不是废除是职责重归这里必须先泼一盆冷水React 19 并没有删除 useEffect也不存在“完全不用写 useEffect”的魔法。官方文档里把 useEffect 的定位重新梳理过强调的是“当你无法用现有特性完成需求时才需要用到 Effect”这种思路。从我的实践体会来看新特性替代掉的是那批“因为缺少更好的工具所以被迫用 useEffect/useState 拼出来的副作用”。典型例子有三类乐观更新以前需要手动维护“临时成功态 失败回滚 实际成功同步”现在 useOptimistic 一步到位。表单提交状态以前要自己搞 pending、error、success 三个 state再配合 useEffect 监听提交结果现在 useActionState / useFormStatus 原生支持。异步资源消费以前用 useEffect 发请求 setState导致在水合、竞态、重复请求上反复踩坑现在 use() 配合 Suspense 从渲染层直接消费。但还有一类 useEffect 是无论如何都应该保留的和 React 外部系统同步。比如订阅第三方事件源、操作浏览器原生 API、手动操作 DOM、接入非 React 管理的图表库。这些场景里 useEffect 就是正确工具因为它就是 React 留下的“逃生舱”。所以更准确的说法是React 19 让 useEffect 从“默认选项”变成了“兜底选项”。这个心智转变比学会几个新 API 重要得多。2. useOptimistic把“乐观更新”从 useEffect 手里彻底接走2.1 老写法回顾useEffect 是怎么处理乐观更新的先说个场景你在做一个点赞功能用户点击后希望按钮立刻变成“已点赞”同时后台请求继续发。如果等接口返回再更新 UI网络慢的时候用户会明显感觉到卡顿。这就是乐观更新的经典场景。以前我的写法大概是这样的const [liked, setLiked] useState(false); const [pending, setPending] useState(false); const handleLike async () { setPending(true); setLiked(true); // 乐观更新 try { await likeRequest(); } catch (e) { setLiked(false); // 失败回滚 } finally { setPending(false); } }; useEffect(() { // 如果别的组件也改了 liked这里要同步 }, [liked]);看起来问题不大但实际项目里要比这复杂你要处理接口失败后的错误提示、要防止用户重复点击、要在多个组件共享同一份数据时保证状态一致。最难受的是如果这个“liked”状态来自全局 store你还得在 useEffect 里监听 store 变化再回写 UI一不小心就出现状态不一致。这类逻辑写多了你会发现 useEffect 的依赖数组里装满了各种状态而它真正的用途只是“同步两个数据源”。这里还有一个很隐晦的坑乐观更新和实际更新的错位。用户点赞后立刻看到成功但如果另一个操作也修改了同一份数据useEffect 的触发时机是不可控的很容易出现“闪一下旧数据”“回滚后又变回新数据”的诡异表现。2.2 新写法useOptimistic Action 的完整流程React 19 的 useOptimistic 就是为这个场景设计的。它不再要求你自己维护“临时状态”和“真实状态”的同步关系而是让你声明式地告诉 React“这个状态是乐观值一旦触发了某个动作UI 先用我给出的临时值”。import { useOptimistic, useTransition } from react; function LikeButton({ liked, onLike }) { const [isPending, startTransition] useTransition(); const [optimisticLiked, addOptimisticLiked] useOptimistic( liked, (state, newLiked) newLiked // 更新函数返回乐观后的状态 ); const handleLike () { // 在 transition 里同步触发乐观更新 startTransition(async () { addOptimisticLiked(!liked); // 立刻把 UI 切到新状态 await onLike(); // 发请求 }); }; return ( button onClick{handleLike} disabled{isPending} {optimisticLiked ? 已点赞 : 点赞} /button ); }这里的关键就是addOptimisticLiked。它的作用不是直接修改状态而是告诉 useOptimistic“这次更新你先把 UI 临时变成这个值”底层真实状态liked不会立刻改变。当onLike()这个异步操作最终完成并且 React 完成重新渲染后useOptimistic 会自动丢弃临时值UI 切换回真实状态。这样就省掉了三个东西手动保存“真实值”和“临时值”的双份状态、每次操作后“对账”的 useEffect、以及失败回滚时手写的补偿逻辑。因为 Action 内部抛异常时React 会保证 UI 回滚到调用前状态。2.3 使用 useOptimistic 的注意事项第一useOptimistic 必须和某个“触发函数”配合才能真正发挥作用。它本身不发起请求也不管理请求生命周期。就像遥控器不能自己开电视它得配合 startTransition 里的异步任务才有意义。第二乐观更新的“回滚”是自动的但前提是异步函数必须抛出异常。如果你在 onLike 里自己 catch 了错误并且吞掉React 永远不知道请求失败了UI 就会停在错误的乐观状态上。第三不要在 setState 或 useOptimistic 的更新函数里执行有副作用的操作。React 的更新函数可能是重复调用的不能在里头发请求、改 DOM。第四嵌套乐观更新的场景要小心。比如一个列表里每个子项都能点赞你可以在父组件用一个 useOptimistic 管理整个列表状态更新函数里根据 id 找到对应项修改。这种情况下更新函数要保持纯函数不能直接修改原数组要返回新数组。3. Actions、useActionState 与表单状态链路重构3.1 过去的表单加载状态有多痛表单提交一直是 React 开发里最繁琐的部分之一。以前我做一个“新增文章”的表单大概需要这么一堆东西const [title, setTitle] useState(); const [content, setContent] useState(); const [error, setError] useStatenull | string(null); const [isPending, setIsPending] useState(false); const [result, setResult] useStatenull | Article(null); const handleSubmit async (e: FormEvent) { e.preventDefault(); setIsPending(true); setError(null); try { const data await createArticle({ title, content }); setResult(data); setTitle(); setContent(); } catch (err) { setError(err.message); } finally { setIsPending(false); } };这个写法本身不算错但你在真实项目里还需要考虑提交成功后要不要重置表单失败后错误提示要显示在哪里如果用户在 pending 状态下切换页面组件卸载后再 setState 会不会警告这些逻辑一旦多起来就不可避免地要用 useEffect 去“监听某个状态变化再做额外处理”。而且很多团队会把表单状态放到全局 store 里导致每个字段都要写 action、reducer代码量翻了三倍但功能没变多。3.2 useActionState把状态收进一个 hookReact 19 里新增的useActionState直接把“提交动作 提交状态 返回值”打包成了一个 hookimport { useActionState } from react; async function createArticleAction(prevState, formData) { const title formData.get(title); const content formData.get(content); try { const article await createArticle({ title, content }); return { status: success, article }; } catch (e) { return { status: error, message: e.message }; } } function ArticleForm() { const [state, formAction, isPending] useActionState(createArticleAction, { status: idle, }); return ( form action{formAction} input nametitle / textarea namecontent / button disabled{isPending} {isPending ? 提交中... : 提交} /button {state.status error p{state.message}/p} {state.status success p创建成功/p} /form ); }注意这里和之前最大的区别state 是 action 的返回值不再是组件里手动 setState 出来的。所以你再也不需要 useEffect 去监听“成功状态”然后弹提示、重置表单了。Action 函数本身就是一个完整的流程处理函数它接收上一个 state 和 formData返回新 state。这个思路有点像 reducer但它是为“异步提交”设计的。特别是isPending它是 React 内部基于 action 执行状态自动推导出来的比自己维护的isPending可靠得多因为后者经常在“组件卸载/请求被取消/并发提交”这些边界场景下出现状态泄露。3.3 Form Actions 与 useFormStatus 的组合除了 useActionStateReact 19 还允许直接把异步函数传给form action{fn}配合useFormStatus在子组件里读取提交状态function SubmitButton() { const { pending } useFormStatus(); return button disabled{pending}{pending ? 保存中... : 保存}/button; } function ProfileForm() { async function updateProfile(formData) { await fetch(/api/profile, { method: POST, body: formData }); } return ( form action{updateProfile} input namenickname / SubmitButton / /form ); }useFormStatus只能在form的子组件里调用pending会自动反映这个表单的 action 是否在飞。这个 API 特别适合做“提交按钮拆到独立组件”的场景因为以前为了让按钮感知 pending你得把状态提升到两个组件的共同父级再用 props 层层传下去。这个设计的巧妙之处在于提交状态的来源从“手动 setState”变成了“表单 action 的自动状态”。你不需要 useEffect 在提交成功后清空表单也不需要担心错误状态忘了重置。数据流变成了一根单向管道用户提交 - action 执行 - 返回新 state - UI 自动更新。我自己的体会是只要表单逻辑不涉及“非常规的状态联动”比如字段 A 的值要影响字段 B 的校验规则完全可以无脑迁移到 useActionState。代码量的减少是肉眼可见的而且心智负担低很多——不需要再问“我这个 loading 状态在哪个组件里要不要放到 context 里”4. use()把异步资源消费带进渲染层4.1 use() 的基本用法上一个让我觉得“这个 API 应该早点出”的就是use()。它的作用是在渲染过程中直接读取一个 Promise 或者 Context 的值而不需要先通过 useState useEffect 把异步数据搬到状态里。最简单的用法是这样的import { use } from react; function Article({ articlePromise }) { const article use(articlePromise); return h1{article.title}/h1; }注意use()不是 hook它不需要遵守 hooks 规则可以在条件语句和循环中使用。这一点和所有我们熟悉的 useState、useEffect 都不一样。在使用 Promise 时use()需要配合Suspense使用。Promise 还没 resolve 时React 会“卡住”这个组件的渲染向上寻找最近的 Suspense fallback 显示加载中状态。当 Promise resolve 后组件恢复渲染直接拿到数据。4.2 对比useEffect 加载数据 vs use() 加载数据老写法的典型代码function Article({ id }) { const [article, setArticle] useState(null); const [loading, setLoading] useState(true); useEffect(() { let cancelled false; setLoading(true); fetchArticle(id).then((data) { if (!cancelled) { setArticle(data); setLoading(false); } }); return () { cancelled true; // 手动处理竞态 }; }, [id]); if (loading) return Spinner /; return h1{article.title}/h1; }这段代码里有几个隐藏问题如果 id 变化太快cancelled变量可以避免旧请求覆盖新状态但这属于“自己手写异步取消逻辑”如果fetchArticle内部不是每次都返回新 Promise可能还要考虑缓存如果你在 useEffect 里 setState 的组件已经卸载虽然cancelled能避免报错但无谓的请求还是发了。新写法function Article({ articlePromise }) { const article use(articlePromise); return h1{article.title}/h1; }加载状态完全由外层 Suspense 接管function ArticlePage({ id }) { const articlePromise fetchArticle(id); // 直接创建 Promise不做 await return ( Suspense fallback{Spinner /} Article articlePromise{articlePromise} / /Suspense ); }最明显的差别是不再存在“数据还没回来但组件已经渲染出来”的中间态。渲染只会有两个结果数据在 Suspense 里等待、数据到了直接渲染。你不需要 loading 标记不需要担心 useEffect 的清理顺序也不需要自己处理竞态因为 Suspense 本身保证了最近创建的 Promise 才是当前渲染要消费的。4.3 use() 的服务端场景与设计边界use() 的另一个重要场景是服务端组件RSC。在服务端组件里以前要读一个异步数据源通常得把组件改成 async function直接 await。而 use() 在服务端组件里也可以使用配合 Suspense 做按需加载。比如async function fetchReviews(productId) { const res await db.query(...); return res; } function ProductPage({ productId }) { const reviewsPromise fetchReviews(productId); return ( div ProductInfo productId{productId} / Suspense fallback{div评论加载中.../div} Reviews reviewsPromise{reviewsPromise} / /Suspense /div ); }这种模式的思路是“在父组件发起异步任务把 Promise 传给子组件消费”。Promise 可以被多个组件共享也可以被缓存链路比 useEffect 发请求清晰得多。但需要强调use() 适合的是“渲染依赖的异步数据”不适合“用户操作触发的异步动作”。点击按钮后发请求、根据结果弹提示这种场景应该用 Actions 或普通事件处理函数硬套 use() 会非常别扭。还有一个容易踩的点use() 读取 Promise 时如果 Promise reject 了React 会把它当作渲染错误抛给最近的 error boundary。所以你要为可能失败的资源准备 error boundary而不像以前在 useEffect 里可以自己 catch 然后 setError。这个属于思维方式变化刚迁移的时候容易漏。5. ref 作为 props、ref cleanup 与 DOM 操作的减法5.1 forwardRef 终于要退役了React 19 里一个非常接地气的变化函数组件可以直接接收 ref 作为 props。以前想从父组件操作一个函数组件内部的 DOM 节点必须用 forwardRef 包一层等于给组件额外加一个 ref 槽位。这导致代码里到处都是 forwardRef 包裹、props 穿透、类型标注的噪音。老写法const Input React.forwardRefHTMLInputElement, Props((props, ref) { return input ref{ref} {...props} /; });新写法function Input({ ref, ...props }: Props { ref?: React.RefHTMLInputElement }) { return input ref{ref} {...props} /; }从组件使用者的角度这两种写法调用方式一样差别在组件的定义侧。但你别小看这个改变以前很多组件库为了透传 ref不得不用 forwardRef 包好几层导致 React DevTools 里组件树层级非常深。现在直接写 props 就能拿到 ref组件树更扁平排查问题也更方便。5.2 ref cleanupuseEffect 清理逻辑的替代者这个特性很长一段时间我只在 React 19 RC 的 changelog 里看到但实际用下来非常实用。React 19 允许ref 回调函数返回一个清理函数当 ref 被卸载或者 ref 的值发生变化时会调用这个清理函数function Canvas({ width, height }) { return ( canvas ref{(node) { if (!node) return; const ctx node.getContext(2d); drawSomething(ctx, width, height); return () { // 清理操作清理事件监听、取消动画等 cancelAnimationFrame(rafId); }; }} / ); }以前这类逻辑怎么写要么用 useEffect 监听 [width, height] 然后操作 ref.current要么在组件卸载时手动做清理const canvasRef useRefHTMLCanvasElement(null); useEffect(() { const ctx canvasRef.current?.getContext(2d); if (!ctx) return; const rafId drawSomething(ctx, width, height); return () cancelAnimationFrame(rafId); }, [width, height]);对比可以发现ref cleanup 把“DOM 节点和外部资源的生命周期绑定”这件事从 useEffect 里拆了出来。只要某个资源只和单个 DOM 节点相关就应该写在 ref 回调里而不是 useEffect 里。这减少了 useEffect 的使用场景也让代码更内聚DOM 的创建、使用、销毁都在同一个回调里表达。5.3 哪些 DOM 场景还是得靠 useEffect虽然 ref cleanup 很香但有一种场景它替代不了依赖 React 状态但操作目标不是单个 ref 的场景。比如你要监听窗口 resize 事件这个事件和任何 DOM ref 都无关只和组件生命周期有关那还是要用 useEffectuseEffect(() { const handleResize () setWidth(window.innerWidth); window.addEventListener(resize, handleResize); return () window.removeEventListener(resize, handleResize); }, []);再比如你要在多个节点上注册事件、要在 props 变化时重置第三方图表实例、要在组件卸载时清理全局事件总线……这些仍然是 useEffect 的主场。记住一个判断标准数据源是否跟某个 DOM 节点共存亡。如果答案是“是”用 ref cleanup如果答案是“否”用 useEffect。6. 常见问题与迁移实操建议6.1 React Compiler 和 useEffect 的关系聊 React 19 就绕不开 React Compiler。编译器会自动记住组件的状态依赖帮你避免不必要的重渲染。这直接导致 useMemo、useCallback 在很多场景下不用再手写了官方甚至说 UseMemo/useCallback 这类 API 未来会逐步退出主流。但有个很现实的问题编译器会优化自动记忆不会帮你把 useEffect 删掉。因为 useEffect 是显式声明的副作用编译器无法判断“这个副作用是不是必须的”。所以“告别 useEffect”只能靠你自己改写成新特性来实现编译器不会魔法般地替你完成。所以实际迁移建议是先把依赖 useMemo/useCallback 的负担去掉再一个个审视 useEffect 的场景。哪些能改成 useOptimistic、useActionState、use()、ref cleanup 就改改不了的保留 useEffect 也完全没问题React 团队自己都说了 useEffect 不会消失。6.2 升级到 React 19 前要做的检查第一确认第三方依赖兼容性。特别是 react-router、antd、zustand 这些常用库它们内部可能使用了被废弃的 API。我升级时遇到的最大坑是某些组件库在 React 19 下会触发forwardRef相关警告原因是 React 19 对forwardRef的渲染行为做了调整需要组件库作者适配。第二TypeScript 类型定义。React 19 的 types/react 更新后useRef必须传参数// 老写法React 19 类型下会报错 const ref useRefHTMLDivElement(null); // 新写法 const ref useRefHTMLDivElement(null!);这类类型层面的 breaking change 很隐蔽不会立刻红屏但会在 CI 类型检查时挂掉最好提前跑一遍 tsc。第三React Native 开发者注意React 19 在 React Native 上的适配比 Web 慢半拍。我当时在 RN 项目里测试新架构时发现 useOptimistic 等新 hook 在 RN 新架构下基本可用但个别 API比如 Form Actions在 RN 里意义不大因为没有form这个概念。别急着把 RN 项目全面升到 React 19先拿 Web 项目试验。6.3 避坑速查表场景老做法新做法常见坑表单提交 loading 状态useState 手动 setuseActionState / useFormStatus忘了处理 action 返回值类型乐观更新useState useEffect 对账useOptimistic在更新函数里做副作用异步数据加载useEffect setStateuse() Suspense没有 error boundary 兜底子组件 ref 透传forwardRef直接传 ref prop类型定义没升级DOM 清理逻辑useEffect return cleanupref cleanup 函数误用在全局事件上最后分享一个我实际踩过的坑。刚开始用 useActionState 时我以为 action 的返回值可以直接在 render 里访问于是直接在组件顶层解构 stateconst [state, formAction, isPending] useActionState(submitAction, initialState); console.log(state.someField); // 第一次是 undefined第一次渲染时 state 是 initialState这没问题。但如果你在 action 里返回了一个结构不同的对象比如只在成功时才有某个字段那组件在“提交中”和“提交失败”时访问这个字段就会报错。建议把所有可能的返回值都设计成相同结构或者在渲染前做空值兜底。这类问题在 useEffect 时代不容易出现因为你可以用 useEffect 监听状态变化但新写法下它会在渲染阶段直接炸调试成本反而更高。另一个建议是升级到 React 19 后先别急着把项目里所有 useEffect 全部改掉。我从实践中得到的经验是一次只迁移一个页面优先选择表单密集、交互反馈多的模块比如评论、点赞、订单提交这类场景。这类页面改造成果最明显代码量能砍掉一半。而一些数据展示型页面比如 Dashboard 大屏useEffect 做数据轮询仍然是最直接的方案强行改造反而会让代码更绕。按这个节奏我在一个中后台项目里把 useEffect 使用量从 187 处降到了 92 处不是为降而降而是每删一处都伴随 dependencies 数组的简化、loading 状态变量的减少、组件 return 分支的收敛。这种“代码瘦身”带来的维护收益比数据上的好看要实在得多。