Vue 中 nextTick 有什么作用？

简化版

nextTick 用于在 Vue 完成 DOM 更新后执行回调。因为 Vue 会把同一轮事件中的多次状态变化合并异步更新，所以修改数据后立刻读 DOM 可能还是旧的，需要 await nextTick()。

详细版

示例：

count.value++;
await nextTick();
console.log(el.value.textContent);

Vue 更新不是每次赋值都同步改 DOM，而是把更新放入队列，在当前调用栈结束后批量刷新。这样能避免多次状态修改导致多次渲染。

使用场景：

数据变化后读取最新 DOM 尺寸。
列表渲染后滚动到底部。
弹窗打开后聚焦输入框。

不要把 nextTick 当成通用异步等待工具，它只保证 Vue 的 DOM 更新已经完成。

完整版教学

一、为什么 Vue 要异步更新 DOM

如果一次点击里连续修改多个状态：

a.value++;
b.value++;
c.value++;

Vue 没必要每改一次就重新渲染。它会收集更新，统一在下一轮刷新 DOM，提高性能。

二、数据变了不等于 DOM 立刻变了

响应式数据更新是同步的，但 DOM patch 是异步批量的。因此下面可能读到旧 DOM：

第一行已经把响应式值改好，但组件更新任务会进入队列，同一同步调用栈里仍可能面对旧节点。等待 nextTick 的目的不是让数据生效，而是把读取 DOM 的动作移到这批 patch 完成之后。

visible.value = true;
inputRef.value?.focus();

如果输入框依赖 visible 渲染，应该：

visible.value = true;
await nextTick();
inputRef.value?.focus();

三、nextTick 的调度基础

Vue 会优先利用微任务机制调度更新。具体实现会根据环境选择合适方案。对开发者来说，只需要知道 nextTick 回调发生在本轮响应式更新对应 DOM 刷新之后。

四、不要滥用 nextTick

如果逻辑可以通过 computed、watch、生命周期表达，就不要到处 nextTick。过多 nextTick 往往说明状态设计或组件边界不清。

它主要服务于“必须访问更新后的真实 DOM”的场景。

五、面试追问与工程落地

nextTick 常见追问是“它和 setTimeout 有什么区别”。nextTick 等的是 Vue 当前更新队列刷新完成，语义和框架更新绑定；setTimeout 等的是下一轮宏任务，不保证刚好对应 Vue DOM 更新，也可能引入不必要延迟。

还会问多次修改状态需要几个 nextTick。通常同一轮同步代码里的多次状态修改会被合并，一次 await nextTick() 就能等到这一批 DOM 更新完成。如果 nextTick 后又修改状态，再读 DOM 就需要再次等待。

工程里常见场景是打开弹窗后聚焦输入框、列表新增消息后滚动到底部、展开区域后测量高度。只要不是“必须读更新后的 DOM”，就先考虑 computed/watch/lifecycle，不要滥用 nextTick。

六、用一轮更新队列解释等待边界

状态赋值本身是同步的，组件渲染 effect 被触发后会进入 Vue 的调度队列，同一轮中的重复任务会被去重；调度器刷新虚拟 DOM 和真实 DOM 后，nextTick 返回的 Promise 才继续。因此它等待的是当前待处理的 Vue 更新批次，不是任意异步任务，也不是浏览器已经完成绘制。

同步代码：count++ → count++ → count++
                    │ 三次触发，同一组件任务去重
                    ▼
          Vue 调度队列刷新一次
                    ▼
             DOM patch 完成
                    ▼
           await nextTick() 继续

假设同一调用栈内连续把 count 从 0 改到 1、2、3，业务状态立即是 3，但组件通常只需按最终值完成 1 批 DOM 更新。一次 await nextTick() 能等待这一批；若等待后又把 count 改成 4，就创建了新的待刷新工作，读取对应 DOM 前需要再次等待。

工具	等待目标	不能保证的事情
`nextTick`	当前 Vue DOM 更新队列完成	网络完成、浏览器绘制完成
`setTimeout(..., 0)`	后续宏任务机会	精确对应某一批 Vue 更新
`requestAnimationFrame`	下一次绘制前回调	Vue 一定有待更新内容
`watch(..., { flush: 'post' })`	指定依赖更新后的组件 DOM	适用于所有命令式流程

需要测量布局时，nextTick 确保 DOM patch 已发生，但浏览器布局与绘制阶段仍由渲染流水线决定；需要等待视觉帧时可能还要结合 requestAnimationFrame。反过来，如果逻辑只依赖响应式数据而不读 DOM，通常根本不需要 nextTick。

心法：先问“我是否必须读取这次状态变化产生的新 DOM”；答案不是肯定时，不要把 nextTick 当成消除时序问题的万能胶。

七、常见误区与追问

误区：修改 ref 后数据也要等 nextTick 才变化。 响应式状态同步更新，延后的是组件 DOM 的批量刷新。
误区：nextTick 等同于 setTimeout 零延迟。 前者与 Vue 更新队列绑定，后者安排宏任务，语义和时机不同。
误区：await nextTick 能等待接口请求结束。 它只等待 Vue 当前更新工作，不跟踪 fetch、定时器或其他业务 Promise。
追问：同一轮修改三次状态需要 await 三次吗？ 通常任务会去重，一次等待即可观察这一批最终 DOM；后续新修改则属于新批次。
追问：nextTick 后页面一定已经绘制到屏幕吗？ 不一定，它保证 Vue DOM 更新完成，不等同于浏览器完成布局、绘制和合成。
追问：watch flush post 能否替代 nextTick？ 对某个依赖变化后读取组件 DOM很合适；命令式流程中直接 await nextTick 往往更清晰。
追问：为什么滥用 nextTick 是设计信号？ 它可能掩盖重复状态、错误组件边界或本可由 computed/watch 表达的依赖关系。

八、加强记忆

nextTick 记成“等 Vue 把 DOM 作业交完”。改数据后要读新 DOM，用它；普通异步流程、接口请求，不该依赖它。

它等待的是 Vue 当前刷新队列，不承诺接口完成，也不承诺浏览器已经把像素绘制到屏幕。

简化版

详细版