用过 Vue 的人几乎都写过 nextTick，但很少有人真正说清它在等什么。为什么弹窗打开后在 nextTick 里拿图表容器，宽高还是 0？
一、从一个常见的困惑说起
你在项目里一定遇到过这样的场景：点击按钮打开一个弹窗，弹窗里有个图表，于是你在打开弹窗后写了 nextTick，然后初始化 ECharts------ 结果图渲染出来是空白的，或者缩成一小团。打印容器一看，宽高都是 0。
你可能会疑惑：nextTick 不是 "等 DOM 更新完" 吗？为什么 DOM 都有了，尺寸还是 0？
要回答这个问题，得先弄清楚 Vue 的更新机制。
二、Vue 的异步更新队列
当你修改一个响应式数据时，Vue 并不会立刻更新 DOM。它的做法是：把组件的更新任务放进一个异步更新队列，并且做去重 ------ 同一轮事件循环里，即使你连续改了十次同一个数据，Vue 也只保留一次更新任务。
等当前这段同步代码执行完，Vue 再在微任务里统一刷新队列，完成 DOM 的 patch。这就是 Vue "批量更新" 的核心机制，也是它性能好的原因之一：一万个数据变动，最终可能只触发一次真实的 DOM 操作。
而 nextTick(callback) 做的事情非常简单：把自己的回调追加到这个刷新队列之后。所以回调执行时，Vue 自己的 DOM 更新已经完成了 ------ 这就是它唯一的保证，也是它唯一的承诺。
三、它是微任务，不是 "等浏览器画完"
在实现层面，Vue 3 的 nextTick 直接基于 Promise.then 构建，并与响应式调度器紧密结合；Vue 2 则优先用 Promise.then，在不支持 Promise 的老浏览器中才降级到 MutationObserver、setImmediate、setTimeout。所以 nextTick 的本质是微任务。
很多人最大的误区就在这里：把 nextTick 当成 "等页面渲染完"。
实际上，微任务执行完之后，浏览器还要经历样式计算（style）、布局（layout）、绘制（paint）这些步骤，页面才会真正呈现出来。nextTick 完全不保证这些，更不保证图片加载完成、字体就绪、异步组件加载完成，或第三方库初始化完毕。
它只保证一件事：Vue 的虚拟 DOM 已经变成了真实 DOM。 至于这个真实 DOM 此刻 "长什么样"（宽高多少、位置在哪），那是浏览器渲染流水线的事，nextTick 管不着。
理解了这一点，前面弹窗图表宽高为 0 的问题就真相大白了：DOM 节点确实插入了，但浏览器还没完成布局计算，或者父容器的过渡动画 / 尺寸还没生效，所以 offsetWidth 就是 0。
四、五个高频踩坑场景与正确的解法
坑 1：弹窗 / 抽屉 / Tab 切换后初始化图表
如上所述，nextTick 后容器可能已存在，但宽高是 0。
✅ 解法：在 nextTick 之后再包一层 requestAnimationFrame（等浏览器完成布局），或者用 ResizeObserver 监听容器尺寸，尺寸非 0 时再初始化图表。后者更稳，因为它能感知后续任何尺寸变化。
坑 2：列表更新后去算滚动高度
列表用 v-for / v-if 切换后，nextTick 里 DOM 有了，但图片没加载、字体没就绪，算出的高度依然不准。
✅ 解法：监听图片 load 事件后再计算；涉及字体用 document.fonts.ready；动态内容交给 ResizeObserver 修正。
坑 3：父组件的 nextTick 等不到异步子组件
子组件如果是异步组件（() => import(...)），父组件在同一次 tick 里拿到的可能是不完整的结构 ------ 异步组件的加载根本不在 DOM 更新队列里。
✅ 解法：用 <Suspense> 包裹异步子组件；或者让子组件在 onMounted 时显式 emit 一个事件，比 "硬等 nextTick" 可靠得多。
坑 4：在 nextTick 里又改数据
在 nextTick 回调里再修改响应式数据，会触发新一轮更新，写得不好甚至形成近似循环的更新，页面反复重渲染。
✅ 解法：加条件守卫，只有满足条件才修改；或者把逻辑拆成多个独立的更新步骤，不要在一个回调里反复横跳。
坑 5：SSR 环境里操作 DOM
服务端渲染没有真实 DOM，nextTick 相关的 DOM 操作会直接报错。
✅ 解法：所有依赖 DOM 的逻辑统一放到 onMounted 钩子里，那是客户端独有的生命周期。
另外一个实用提示：写自动化测试时，记得用 flushPromises（或 Vue Test Utils 提供的工具）确保更新队列清空，否则很容易出现 "明明逻辑对，测试却失败" 的诡异情况。
五、推荐写法：能不用 nextTick，就不用
nextTick 是一把好锤子，但不是所有钉子都得用它。Vue 3.5 之后，官方提供了语义更清晰的替代方案：
useTemplateRef()：获取模板引用的新姿势，类型推断更友好，替代杂乱的ref(null)命名约定。watch(source, cb, { flush: 'post' })：flush: 'post'让回调在 DOM 更新之后执行，可以替代相当一部分nextTick/onUpdated的用法，把 "数据变了 → DOM 更新 → 执行回调" 这条链表达得清清楚楚。<Suspense> + defineAsyncComponent：异步组件的加载、占位、错误态交给框架统一处理，不要手动硬等。ResizeObserver / IntersectionObserver：凡是和 "元素真实尺寸 / 可见性" 相关的问题，才真正该交给它们 ------ 它们是唯一能感知浏览器渲染结果的 API。
Vue 3.6 的 Vapor 模式会进一步优化调度和渲染性能，但 nextTick 的语义不会变：它始终是微任务边界，不跨越浏览器渲染帧。 另外，Vue 2 已于 2023 年底停止维护，新项目不必再考虑它的降级方案，直接基于 Promise 微任务模型思考即可。
六、总结：把它当 "边界"，别当 "万能等待"
一句话记住 nextTick：
nextTick 等的是 Vue 异步更新队列的刷新，不是浏览器渲染完成。
记住三件事，基本就不会踩坑：
- 它是微任务，保证的是虚拟 DOM 已变成真实 DOM；
- 尺寸、图片、字体、异步组件 ------ 这些浏览器层面的东西，用
requestAnimationFrame、ResizeObserver、<Suspense>各自对应的工具去等； - 优先考虑
watch flush: 'post'等声明式方案，把nextTick留给真正需要 "手动插队" 的场景。
把 nextTick 当作 "微任务边界" 而不是 "万能等待"，你的代码才会既正确，又高性能。