批量更新是响应式系统将多次数据变更合并为一次执行的机制，通过异步微任务队列实现延迟执行与任务去重，确保同一组件仅渲染一次、状态取最终值，并在浏览器渲染前完成DOM更新。

批量更新是指响应式系统在一次事件循环中，将多个数据变更引发的更新任务合并为一次执行，避免重复渲染或计算。它不是“等所有变化做完再更新”，而是通过异步队列 + 去重机制，在 JS 同步代码执行完毕后、浏览器渲染前，统一刷新所有待处理的副作用。

为什么多次赋值只触发一次视图更新？

关键在于“延迟执行”和“任务去重”。当 state.count++ 执行 10 次时，每次修改都会触发 trigger，但不会立刻运行组件的 render 函数；而是调用 queueJob 把渲染任务加入全局队列。该函数会检查任务是否已在队列中，相同任务（比如同一个组件的更新）只保留一份。

• 同一组件的渲染任务，无论被加入队列多少次，最终只执行一次
• 不同组件或 watch/computed 的更新任务，只要发生在同一 tick 内，也会被收进同一个队列
• 队列不会马上执行，而是通过 Promise.resolve().then(flushJobs) 推入微任务队列

更新时机：为什么是微任务而不是 setTimeout？

Vue 默认使用微任务（如 Promise.then 或 queueMicrotask）来调度 flushJobs，因为微任务在当前 JS 栈清空后、渲染前立即执行，延迟最小。这保证了：

• 用户操作（如点击、输入）后的状态更新能尽快反映到界面上，不卡顿
• 多个同步修改共享最新状态——比如连续设置 a = 1; a = 2; a = 3，render 函数拿到的是最终值 3，而非中间态
• 若降级为 setTimeout（宏任务），则要等到下一轮事件循环，UI 响应变慢

底层依赖哪些核心变量和逻辑？

批量更新不是黑盒，它由几个关键结构协同完成：

• queue：存放待执行的 job（effect.run、component update 等）
• isFlushPending：布尔标记，确保微任务只被调度一次，防止重复注册 Promise.then
• activeEffect / targetMap：支撑依赖收集，让 trigger 知道“谁该被加入 queue”
• effect.scheduler：每个副作用可自定义调度方式，runtime-core 中统一设为 queueJob

它和 nextTick 是什么关系？

nextTick 不是批量更新的原因，而是它的出口和接口。flushJobs 执行完后，所有 DOM 更新已完成，此时调用 nextTick 回调，开发者就能安全地读取更新后的 DOM 元素。换句话说：

• 你写的 this.count++ → 触发 queueJob → 注册微任务 → flushJobs → 更新 DOM
• 你写的 nextTick(() => {...}) → 被推入另一个回调队列 → 在 flushJobs 完成后立即执行
• 所以 nextTick 是“等批量更新结束”，不是“等某个数据更新”