从Vue转React的同学大概率都经历过这样一个“不适应期”在Vue里写惯了this.$nextTick(() { ... })到了React发现无论怎么找都找不到同名API。第一次在React里遇到“我明明setState了马上读DOM却还是旧值”估计不少人会愣一下然后去搜索引擎敲出今天这个标题。我这篇不打算绕弯子。先给结论React确实没有提供和$nextTick长得一模一样的API但它的声明式渲染体系里有几种方式可以在不同精度上实现同样的效果——而且某些场景下比$nextTick更顺手。文章会从Vue的$nextTick原理讲起把手把手拆解React里等价的三种写法useLayoutEffect、自定义nextTick工具函数、以及flushSync。这篇文章适合谁看第一类是想搞清这两个框架更新机制差异的人第二类是正在做Vue转React的技术迁移被“DOM更新时机”逼疯的人第三类是单纯想在React项目里复刻一套nextTick风格的调用API的人。我尽量把前后因果讲透让读者看完之后不只是会用还能跟同事解释清楚“为什么我们不直接在React里照搬nextTick”。1. 先拆穿Vue的$nextTick它到底在哪个时机执行回调先别急着写React我们把参照物本身搞明白。很多教程只说“nextTick在DOM更新后执行回调”但DOM更新后这四个字在不同框架里有完全不同的含义。Vue的nextTick严格来说是在当前同步代码运行完毕、组件状态变更已经完成patch更新DOM之后立即执行回调。1.1 Vue为什么需要异步更新Vue的状态更新是异步批量的。你在一个for循环里连续修改data中的同一个字段十次Vue不会渲染十次而是只渲染最后一次。它会先把修改推到调度器的待处理队列里等当前同步代码执行完再统一执行diff和patch。这样做的好处很明显省性能。没有异步更新机制的框架在复杂数据变更场景下会触发大量重复渲染滚动列表、拖拽场景很容易卡顿。但代价就是你在同步代码块里改了数据立刻去访问DOM拿到的还是旧值。// Vue中非常经典的反面教材 this.message new message console.log(this.$el.textContent) // 依旧打印 old messageDOM还没有重新patch你想马上拿到更新后的节点内容就得把事情推迟到更新完成之后。$nextTick就是那个“排队口”。它做的事情本质上是把你传进来的回调函数放到一个比更新渲染更晚的时机去执行。注意不是直接丢到setTimeout里它有自己的优先级策略。1.2 从源码层面看Vue 3的nextTick实现Vue 3的nextTick实现非常简单简单到让人有点意外const resolvedPromise /* #__PURE__ */ Promise.resolve() export function nextTickT void( this: T, fn?: (this: T) void ): Promisevoid { const p currentFlushPromise || resolvedPromise return fn ? p.then(this ? fn.bind(this) : fn) : p }核心就一句话p.then(fn)。currentFlushPromise是调度器的刷新Promise当有更新任务正在排队时nextTick会把自己的回调加到这个Promise后面保证回调一定在DOM更新完成之后执行。Vue 2时代的实现稍微绕一点逻辑上是在微任务Promise.then、宏任务setImmediate、setTimeout之间分级回退。但精讲原理它的定位始终是把回调排队到当前状态变更产生的DOM更新结束之后。这也是为什么同样一份代码你改完数据立刻同步读DOM拿不到新值放进nextTick就能拿到——因为回调执行时DOM patch已经结束了。1.3 Vue nextTick和“下一个宏任务”不是一回事这里最容易踩的认知误区是把$nextTick当成setTimeout(callback, 0)。两者都“晚一点执行”但晚的点完全不同。微任务比宏任务先执行Promise回调会在当前宏任务结束之前跑完而setTimeout的回调要等浏览器把当前脚本执行完、进入下一个事件循环才轮到。Vue官方源码选微任务优先意味着$nextTick的回调能够尽早执行你的UI在视觉上感知不到“中间隔了一帧”的卡顿。理解了这个机制后面看React的替代方案思路会清楚很多。2. React为什么没有原生nextTick其实它把“更新后”做成了渲染副产品Vue的编程范式是命令式的你对数据做修改然后告诉框架“等DOM更新了帮我干点事”。React的编程范式是声明式的你描述“当状态变成X之后我应该执行什么副作用”——这个职责天然落在hooks上。所以React不是做不了nextTick而是它的设计哲学里更推荐你换一种方式表达“更新后要做的事”。在React里与Vue$nextTick最接近的原生机制是useLayoutEffect其次是useEffect。2.1 为什么React没有提供nextTick APIReact 18之前setState并不总是异步的。在同步事件处理函数里React 17及以前会走batchedUpdates批量更新但在回调函数、Promise回调、setTimeout等“非批量更新上下文”中setState会同步执行更新逻辑。这意味着开发者写setState之后立刻读取DOM有时候能拿到新值有时候拿不到——行为很不一致。React 18推出并发特性之后所有更新都默认允许被调度、打断、合并。官方干脆把“强制同步立即更新”的方法flushSync放了出来但同时也强调它会破坏并发特性要谨慎使用。所以React的方案不是给你一个通用的nextTick API而是给了你几个不同时间精度、有明确语义的hooks和工具函数。2.2 useLayoutEffect把回调安排在“DOM更新完成后、浏览器绘制前”先看代码function App() { const [count, setCount] useState(0) const ref useRef(null) useLayoutEffect(() { // 这里的代码在 count 变化对应的 DOM 更新完成后执行 console.log(ref.current.textContent) // 永远是最新的 }, [count]) return div ref{ref}{count}/div }useLayoutEffect的执行时序是组件渲染函数执行 - React把JSX对象转成真实DOM并挂载/更新到页面上 - 浏览器还没有绘制这一帧 - 执行useLayoutEffect回调。这个时机和Vue的$nextTick是同一层的——你可以放心读取DOM布局信息比如offsetTop、scrollHeight也可以放心修改DOM样式而不造成视觉闪烁因为浏览器还没来得及把旧画面画出来。有人会问那useEffect呢它确实也是在DOM更新后执行但它在浏览器完成绘制之后才执行读取布局信息没问题但如果此时对DOM做样式修改用户可能看到“先画旧样式、再变成新样式”的一闪效果。精确来说useEffect对应的是“渲染完成后异步阶段”比nextTick要晚一个绘制帧。2.3 不同时机层级一个表格看明白我把三个时间点放在一起对比先有个宏观印象时机React对应APIDOM是否已更新是否已绘制是否能读布局会阻塞绘制吗状态变更后同步代码无除非flushSync否否否-DOM更新后、绘制前useLayoutEffect是否是会回调同步执行绘制完成后useEffect是是是读取安全不会异步执行同步强制刷新后flushSync立即完成是视调用时机是是从这张表也能看出来如果你只是“想让某段逻辑在依赖的值更新后跑一下”用useEffect就够如果你必须拿到更新后DOM的精确尺寸、位置或者要做ScrollTop、Focus管理之类的操作那就选useLayoutEffect。2.4 useLayoutEffect最常见的误用把同步渲染扛在自己身上真实项目里见过不少人因为在useLayoutEffect里做了重计算导致整个页面卡顿。原因很简单这个hook的回调是同步执行的而且它执行时机在绘制之前浏览器这一帧就算等不到你的回调结束也不会先画出来。你在里面放了一个100万次循环用户感觉就是页面卡死了。所以我的建议是布局读取和轻量DOM修正放useLayoutEffect耗时逻辑拆到useEffect或者提前完成计算再通过状态更新触发视图层变更。useLayoutEffect并不是React版的“万能副作用袋子”它只是一把专门修布局的扳手。3. 自己动手写一个React版useNextTick从队列到时机绑定如果团队成员都是从Vue转过来的直接告诉他们“用useLayoutEffect”短期内还是会写错——因为心智模型不对。useLayoutEffect是声明式的而nextTick是命令式的。很多场景里你确实需要在某个事件回调中临时调用“更新后帮我执行某个函数”这时候我们自己封装一个命令式的nextTick也不是不行。3.1 思路一全局队列 主动触发渲染最朴素的思路是维护一个全局回调队列当用户调用nextTick时把回调push进去然后触发一次React渲染更新渲染完成后的useLayoutEffect阶段统一清空并执行队列。// nextTick.js import { useLayoutEffect, useReducer } from react const callbacks new Set() let flush null export function scheduleFlush() { if (flush) return flush () { callbacks.forEach(cb cb()) callbacks.clear() flush null } // 用微任务确保在渲染完成后执行 Promise.resolve().then(flush) } export function nextTick(cb) { callbacks.add(cb) scheduleFlush() }这个方案有个藏在细节里的坑Promise微任务可能跑在React渲染之前还是之后取决于当前是否已经有正在处理的渲染批次。如果在事件回调里调用nextTick此时React已经进入了批处理状态你新增的Promise.resolve().then回调大概率会排在React的调度和commit之后——但这不是一个可以百分之百保证的时序契约。更稳妥的做法是把队列的弹出时机绑定到组件的useLayoutEffect生命周期里// useNextTick.js import { useLayoutEffect, useRef, useCallback } from react export function useNextTick() { const callbacksRef useRef([]) const [, forceUpdate] useReducer(x x 1, 0) const nextTick useCallback((cb) { callbacksRef.current.push(cb) forceUpdate() }, []) useLayoutEffect(() { const cbs callbacksRef.current callbacksRef.current [] cbs.forEach(cb cb()) }) return nextTick }这个useNextTick使用方式很像Vue确实但它有一个语义上的巨大差异调用nextTick时会主动触发一次额外的渲染哪怕没有状态变更。所以这种方案适合“回调本身不修改状态”的场景如果你在回调里又setState会多触发一次无意义的渲染循环。3.2 思路二只封装“下一个微任务”级别的工具如果只是需要把一段代码推迟到当前同步代码之后执行没必要触发渲染。写一个更轻量的纯函数版// utils/nextTick.js export function nextTick(callback) { return Promise.resolve().then(callback) }是不是觉得太简单了它在我们平时处理的80%场景里确实够用比如function handleClick() { setFlag(true) nextTick(() { // 注意此时 DOM 可能还没更新 }) }但前面已经分析过这个方案有一个完全不能忽略的边界如果你依赖的是“DOM已经更新”它不能保证。Promise.resolve().then只是把回调排到了当前宏任务末尾和渲染之间React的渲染调度也走微任务到底谁先谁后答案是“看情况”。所以这个极简版只能用来处理不依赖DOM状态的逻辑取名也得叫nextMicrotask才准确。3.3 何时要认真考虑自己封装何时直接劝退经历过几次实际项目打磨之后我的结论是如果你想模拟Vue nextTick“DOM已更新”的语义不要用纯Promise微任务版本用useLayoutEffect思路封装。如果你只是想把一个动作从当前同步栈里摘出来、避免阻塞主线程用纯微任务版本就够了。如果你在做跨项目SDK需要对外暴露一个与框架无关的“下一帧执行”API建议用requestAnimationFrame实现但要注意它受标签页后台运行影响。还有一条团队大面积从Vue转React时与其强行复刻nextTick API不如先做一次“Vue生命周期到React hooks心智模型”的培训。这不是技术问题是思维范式问题。4. flushSyncReact官方提供的“强制立即更新”特例如果你在事件回调里同时想满足两个需求——既更新状态、又立刻读取最新DOM那不用花哨的自定义工具React官方给了flushSync。4.1 flushSync怎么用import { flushSync } from react-dom function handleAddItem() { const newItem { id: Date.now(), text: new } flushSync(() { setList(prev [...prev, newItem]) }) // 到这里DOM已经同步更新完成 listRef.current.scrollTop listRef.current.scrollHeight }这和Vue的this.$nextTick(() { ... })体验非常接近区别在于flushSync是在setState调用时就同步强制刷新而不是等着DOM更新后把回调送进去。它是“阻塞式”的更新方式。在使用它的代码块里React会关闭自动批处理立即执行渲染和commit。4.2 flushSync的生命周期与性能代价能用但别乱用。flushSync的代价有三个维度。一是它破坏了React 18的并发特性。React 18的调度器本可以把一次更新标记为低优先级、让出主线程给高优先级交互但flushSync会直接插队执行。频繁使用可能会导致输入框卡顿、动画掉帧。二是它的作用范围比你想的大。flushSync(() setA(...))只保证这个回调内部的更新同步完成但如果你同时调用了setB不在回调内那个更新并不会被同步刷新。处理批量更新时一定要把该同步的set都放进同一个flushSync块内。三是不能在生命周期、render阶段随便调用。React官方文档明确不建议在useEffect、useLayoutEffect里调用flushSync因为它会触发额外的重渲染容易引起无限循环。4.3 flushSync 自定义nextTick的组合姿势我实际项目里最常用到的组合是他俩事件回调里flushSync强制更新完DOM拿到布局信息做滚动修正其他不敏感的副作用逻辑丢到useEffect里自动跑。比如聊天消息列表function handleSendMessage(text) { flushSync(() { setMessages(prev [...prev, { id: Date.now(), text }]) }) // 强制同步后立即滚动到底部 boxRef.current.scrollIntoView({ block: end }) }这样既避免了一帧闪烁也规避了useLayoutEffect里面写业务逻辑带来的维护负担。但反过来如果回调里没有“必须立刻读DOM”的需求就不要加flushSync让React自己决定渲染时机性能通常会更好。5. 三个实战场景数据流刷新、DOM测量、历史状态读取理论讲到这里来三个最容易踩坑的真实场景。这三个场景基本囊括了Vue转React后最常见的nextTick使用动机。5.1 场景一新增列表项后自动滚动到底部这个场景在IM、日志展示、评论区里很常见。Vue里的写法是this.messageList.push(newMsg) this.$nextTick(() { this.$refs.container.scrollTop this.$refs.container.scrollHeight })React里等效写法我推荐useLayoutEffect把滚动逻辑交给依赖项触发const listRef useRef(null) useLayoutEffect(() { listRef.current.scrollTop listRef.current.scrollHeight }, [messageList]) // 你在任何地方 setMessageList 新消息DOM更新后会自动滚动到底部有没有问题有一个很隐蔽的坑如果列表更新之前用户已经在往上翻看历史消息scrollTop scrollHeight会把用户粗暴地拉到最底部体验很糟糕。正确做法是记录“更新前是否已经在底部”const stickToBottomRef useRef(true) function handleScroll() { const el listRef.current stickToBottomRef.current el.scrollHeight - el.scrollTop - el.clientHeight 20 } useLayoutEffect(() { if (stickToBottomRef.current) { listRef.current.scrollTop listRef.current.scrollHeight } }, [messageList])这个场景说明了一个重要问题nextTick给你的只是“时机”真正比你代码质量的是你在这个时机里做什么判断。5.2 场景二图表数据更新后测量容器高度第二个常见场景是第三方图表库这一类库很多接管了DOM渲染。你在React里更新了数据源图表库内部异步重绘你马上读容器尺寸可能图表还没画完拿到的容器高度是缩水版。我的处理套路是三步走先useLayoutEffect里拿到容器最新的offsetHeight把它存入state将高度作为prop传给图表组件的自适应配置。const [containerHeight, setContainerHeight] useState(0) const containerRef useRef(null) useLayoutEffect(() { setContainerHeight(containerRef.current.offsetHeight) }, [data]) // 数据更新后重新测量这里要注意setContainerHeight又会触发一次渲染所以理论上这一帧会重绘两次但在实际渲染中用户几乎感知不到。如果图表库的绘制是异步的可能还需要配合ResizeObserver监听容器尺寸变化这是另一个topic就不展开了。5.3 场景三事件回调里做数据上报最容易被nextTick思想带偏最后一个场景是我见过的Vue转React开发者最爱犯的错在事件回调里连续修改多个状态然后用nextTick挨个读取状态值做埋点。// 错误示范试图在 React 里模拟 Vue 的响应式读取 function handleSelect(item) { setSelected(item) setVisible(true) nextTick(() { sendTrack(selectedRef.current) // 以为能拿到最新的 selected }) }React的状态更新是异步且批量的即便你在nextTick里读取也可能读不到最新的state——因为state的更新发生在渲染阶段nextTick的回调能干等但状态值不一定已经进入渲染。React官方推荐的做法是在事件回调里直接记录操作参数function handleSelect(item) { setSelected(item) setVisible(true) sendTrack(item) // 直接传参不用读state }这背后的思路差异是Vue开发中你习惯了“我改数据改完获取数据的最新值”React更希望你“在这个事件里你把需要的数据都直接拿到手”。如果你在React里强行模拟Vue的nextTick却读不到状态不是实现方式写错了而是思路本身与React的设计哲学冲突了。5.4 方案选择速查表最后给一张可以直接贴在项目文档里的速查表你要解决的问题推荐方案不推荐方案状态更新后自动执行副作用useEffectnextTick函数DOM已更新后需读布局/改样式useLayoutEffect自封装微任务版本事件回调内同步拿到最新DOMflushSync包裹setStateuseEffect跑得太晚只是把代码推迟到下一个事件循环Promise.resolve().thenrequestAnimationFrame跨组件共享更新后回调自定义useNextTick队列全局变量裸奔用方案之前琢磨一下你到底需要的是“时机”还是“结果”如果你真正关心的是“DOM变成什么样子了”“布局尺寸变成多少了”那就用hooks或者flushSync如果你只是想把一段逻辑挪个位置执行那才是nextTick工具函数的适用场景。我自己经历过一段时间的切换期说点掏心窝的话在React里强行寻找nextTick的替身本质上是把命令式框架的习惯带到声明式框架里来。Vue给了你一个可以随意操作时机的工具箱React则要求你把“何时做什么”预先写成依赖关系。刚开始总想找回老写法但当你习惯用useLayoutEffect和useEffect拆分副作用之后会发现声明式的表达反而更可预测——因为渲染时机与依赖绑定不会出现“nextTick回调里又改数据导致多跑一次更新”的麻烦。如果你真的需要封装一个nextTick工具我建议把调用方式设计成useNextTick()而不是导出一个纯函数。把队列挂到组件实例上配合useLayoutEffect确保时机准确你的团队成员用起来也最顺手。记住核心原则时机精度决定方案选型别为了一个API的相似度牺牲代码的可维护性。
