先记住这个答案
Vue 会缓冲由响应式变化引起的组件节点更新。修改状态后 await nextTick，可以等待对应的更新刷新完成，再读取新文本、访问新出现的模板引用或执行节点操作。它不等待未来的网络响应、图片解码、任意异步子组件或动画结束，也不等于浏览器已经绘制了一帧。先明确需要等待哪次更新，再把等待写在该变化之后。
- 先修改状态，再等待对应更新刷新
- 适合一次操作后的节点访问
- 不代替网络、资源与动画的完成信号
需要新节点时才有等待的价值
例如点击按钮打开输入框，立即读取模板引用可能还是空，因为条件状态已经改为真，节点却尚未创建。等待本轮刷新后才能访问新引用，再执行聚焦或读取内容，这比固定等待几十毫秒可靠。
若只是根据刚赋的新值计算数字，直接读取响应式状态即可，不需要 nextTick。把所有逻辑都包进等待会增加异步边界，还可能让任务在恢复时面对已经变化的用户意图。
把节点读取组织为更新后的步骤
下面的函数先修改 count，再等待刷新，通过传入的读取函数获取节点文本。调用方应在已挂载组件的事件处理中使用它，并让读取函数通过模板引用定位节点，避免依赖全局重复的元素编号。
例子把读取函数注入，便于在测试中控制节点是否存在。即使等待成功，读取结果仍允许为空，因为组件可能在等待期间离开页面；这和 Vue 是否完成刷新是不同的问题。
import { nextTick } from 'vue'
import type { Ref } from 'vue'
async function incrementAndRead(count: Ref<number>, readText: () => string | null) {
count.value++
const immediately = readText()
await nextTick()
const afterFlush = readText()
return { immediately, afterFlush }
}在显示 count 的已挂载组件上，从零开始调用会先读到旧文本零，刷新后读到一。函数只承诺等待 Vue 更新流程，不承诺节点一定存在；调用方可在返回空值时跳过后续 DOM 操作。
把外部完成条件分开等待
请求返回后再赋值，需要先等待请求成功并处理错误，随后才等待由赋值引发的节点刷新。在请求还没完成时提前 nextTick，不会替你等待那份数据，也不会知道之后将出现什么更新。
尺寸受图片和字体影响时，应监听相应加载或尺寸变化；动画结束则使用过渡完成信号。需要下一次浏览器绘制时机时也应明确采用对应浏览器 API，不能把框架队列刷新与屏幕显示完成混为一谈。
容易答错的地方
- 把 nextTick 放在状态变化之前
- 它只能等待当时相关的刷新，不能预知稍后才发生的异步赋值。要操作某次更新生成的节点，应先完成该状态变化，再等待，而不是在函数开头随手等待一次就认为后续节点都就绪。
- 连续多次等待来修复未知时序
- 如果一次等待后仍没有目标，可能是条件未满足、异步组件未解析或请求尚未返回。应找到真正的完成信号，多次 nextTick 只是在尝试碰巧等到，无法建立可靠的依赖顺序。
面试官还会怎么问？
await nextTick 后可以保证元素一定存在吗？
不能。它保证的是相关更新刷新，而模板条件可能为假，节点可能已移除，组件也可能在等待期间卸载。读取引用时仍需判空；若业务要求必须存在，应先确认显示条件和生命周期。
和 watch 的 flush post 相比如何选择？
一次点击更新后接着操作节点，写在事件函数中的 nextTick 能保留清楚的顺序。多个入口持续改变同一状态并需要同步节点时，集中使用 post 监听更便于维护共同逻辑与清理。
为什么等了 nextTick 图片高度还会变化？
图片的加载与解码属于外部资源过程，不由这次 Vue 更新刷新决定。需要在图片完成或容器尺寸变化时重新测量，并考虑失败和取消路径，不能把第一次节点插入当成最终布局稳定。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。