先记住这个答案
响应式状态在赋值后立即改变，但依赖它的组件更新通常先被安排进队列，同一轮中重复的更新任务可以去重，随后刷新时使用最新状态生成节点结果。这样连续多次修改不必重复渲染所有中间值。这个保证有边界：跨越等待刷新或不同异步任务可能形成多轮更新，同步侦听器也不会沿用这种批量合并，不能笼统说任意修改都只执行一次。
- 状态赋值立即生效，节点更新可以延后
- 重复组件任务合并后读取最终状态
- 跨刷新边界会出现新的更新轮次
批处理减少无意义的中间渲染
点击处理函数可能同时更新标题、数量和选中项，如果每次赋值都完整刷新，用户最终只看到最后结果，却付出多次中间渲染的成本。把相关更新延后到同步工作结束后处理，可以减少这类重复工作。
这不意味着状态读写也异步。赋值后下一行读取 count.value 会立即得到新值，而读取模板节点仍可能是旧文本；调试时必须明确自己观察的是数据还是已经应用到界面的结果。
直接记录组件渲染次数
示例组件每次渲染时记录读取到的值。先挂载，再在一段同步代码中将 count 改为一、二、三，等待更新后通常只多一次渲染，记录中由初值零直接到最终三。
这个计数用于验证单个组件和受控输入，不应在产品里靠渲染函数的副作用驱动逻辑。复杂父子更新、条件移除或开发工具干预需要另行分析，实验结果不能扩大为所有树结构的固定次数。
import { ref, h } from 'vue'
const count = ref(0)
const rendered: number[] = []
const BatchProbe = {
setup() {
return () => {
rendered.push(count.value) // 实验记录，不驱动业务
return h('span', String(count.value))
}
}
}挂载 BatchProbe 后连续赋值一、二、三，赋值结束时 count 已是三，但渲染记录暂时只有零。等待 nextTick 后记录变为零、三，节点也显示三，能清楚分离赋值与刷新。
跨越更新边界就不能继续合并推断
如果先赋值为一并等待 nextTick，再赋值为二并再次等待，就已经主动给了两轮刷新机会。两个网络响应分别到达也可能造成不同轮次，不能仅因它们来自同一次用户操作就要求只渲染一次。
默认侦听器也会批量处理，但不是每种效果都一样；配置 sync 的观察者会更早逐次响应。性能排查时分别记录组件渲染、监听回调和外部请求次数，避免把某一层的合并推导到所有工作。
容易答错的地方
- 认为 Vue 把前几次赋值取消了
- 赋值过程实际发生，普通同步代码可以读到中间状态，同步观察者也可能看到它们。被避免的是部分重复的后续更新工作，而不是业务状态修改被撤销或完全不可见。
- 用任意微任务代替明确刷新等待
- 微任务顺序取决于登记时点和正在进行的更新链，随手等待一个 Promise 不如 nextTick 清楚表达需要等待 Vue 刷新。验证界面时应使用与框架更新语义对应的等待点。
面试官还会怎么问？
为什么一个组件更新仍会修改多个 DOM 节点？
批量去重针对组件更新任务，执行一次渲染后仍要根据前后树差异更新文本、属性或子节点。任务次数与底层节点操作数不是同一指标，性能诊断应区分计算和补丁阶段。
两次 await nextTick 之间改值会合并吗？
第一轮等待已经允许前面的更新完成，之后的新赋值会安排新的工作，通常不能再与已经执行的渲染合并。测试中可以逐轮记录，明确每个等待点将观察窗口分开。
想保留所有输入过程应该监听 DOM 更新吗？
不合适。界面更新可能跳过中间显示状态，操作历史应在输入或业务命令入口记录。这样既能保留事件顺序，也不需要为了日志完整性牺牲组件更新的批处理能力。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。