7.2 异步更新队列的调度与执行顺序

你在代码中修改了某个响应式数据，Vue 并不会立刻去更新 DOM，而是把这次更新任务塞进一个队列，然后在合适的时机一次性清空队列，完成所有更新。这种设计叫异步更新队列，它既保证了性能，又决定了回调函数和生命周期钩子的触发顺序。理解它的调度规则，能让你避免很多“明明数据变了，为什么 DOM 还没变”的困惑。

为什么要用异步队列？

假设一个响应式变量被多个地方依赖，你在同一个函数中连续修改它几次：

<script setup>
import { ref } from 'vue'
const count = ref(0)
const double = computed(() => count.value * 2)

function example() {
  count.value = 1
  count.value = 2  // 如果每次变化都触发更新，这里会重复渲染两次
}
</script>

如果每次赋值都立刻触发视图重绘，会产生大量无意义的重复渲染，最终用户界面只显示最后一次变化（count = 2）的样子。Vue 的做法是：把所有的更新任务收集起来，等到下一个“微任务”执行时，一次性统一处理。这样无论你修改了多少次 count，只有最后一次的状态会被用来生成新的 DOM，中间态直接跳过。

调度机制：一次事件循环只做一次 DOM 更新

Vue 内部维护了一个“更新队列”，并有一个标志位（isFlushing）来避免重复入队。具体流程如下：

数据变化 → 触发依赖这个数据的组件渲染 effect。
effect 不会立即执行，而是将自己推到微任务队列中（通过 Promise.then）。
在同一个宏任务（如一次事件处理函数）中，无论你修改了多少次数据，队列里也只会有这一个组件的更新任务（去重后的）。
当 JavaScript 执行栈清空，微任务开始执行，Vue 取出队列中的所有更新任务，按组件层级顺序依次执行组件的渲染函数，生成新的虚拟 DOM，最终执行一次统一的 DOM 更新。
更新完成后，所有 nextTick 注册的回调被触发，确保你此时能拿到最新的 DOM。

这就是为什么你在代码中修改数据后，立即去读取 DOM 是拿不到最新值的，必须等到第 4、5 步完成。一个直观的例子：

<template>
  <div>
    <span ref="msgSpan">{{ message }}</span>
    <button @click="updateMessage">更新</button>
  </div>
</template>

<script setup>
import { ref, nextTick } from 'vue'
const message = ref('Hello')
const msgSpan = ref(null)

function updateMessage() {
  message.value = 'World'
  console.log(msgSpan.value.textContent) // 仍然是 'Hello'，DOM 还没更新
  nextTick(() => {
    console.log(msgSpan.value.textContent) // 已经是 'World'，DOM 更新完毕
  })
}
</script>

nextTick 的作用正是“等待下一次 DOM 更新完成后”再执行回调。它是我们与异步更新队列交互的桥梁。

执行顺序：组件更新、watch 与 nextTick 的排列

理解这些回调的触发顺序，对复杂交互和测试非常重要。当数据变化时，Vue 会按以下规则调度副作用：

组件渲染：组件更新是队列中最核心的任务，它被标记为 pre 类型的 effect（在 DOM 更新前执行）。Vue 会按 父组件 → 子组件 的顺序执行渲染逻辑，但注意：整个异步队列是一次性清空的，所以父子组件的更新最终会合并到同一批微任务中。
watch / watchEffect：根据配置的不同，执行时机也不同。
watch 默认行为（等同于 flush: 'pre'）：在组件更新之前执行回调。
watch 配置 flush: 'post'：在 DOM 更新之后执行回调，此时可以安全操作 DOM。
watchEffect 默认也是 flush: 'pre'，但可以通过 watchPostEffect 或配置变为 post。
生命周期钩子 updated：在组件 DOM 更新完毕之后调用，属于 post 类。
nextTick：永远在所有上述 DOM 更新任务完成后触发，保证拿到最终渲染结果。

用一个表格来概括典型顺序（假设数据变化发生在同一事件循环内）：

| 阶段 | 执行内容 | 能操作最新 DOM 吗？ |
|------|----------|---------------------|
| 1 | 数据变化，依赖收集，更新任务入队 | 否 |
| 2 | 微任务开始，执行 flush: 'pre' 的 watch 回调 | 否（DOM 还没更新） |
| 3 | 执行组件渲染 effect，虚拟 DOM 生成，patch 到真实 DOM | 否（正在更新） |
| 4 | 执行 flush: 'post' 的 watch 回调、updated 生命周期 | 是（此时 DOM 已更新） |
| 5 | 执行所有通过 nextTick 注册的回调 | 是 |

实用技巧：按需选择回调时机

想要在数据变化后立刻做一些逻辑判断，但不依赖新 DOM？ → 使用默认的 watch 或 watchEffect（pre 阶段）。
需要在数据变化导致 DOM 更新后，测量元素尺寸、计算滚动位置？ → 使用 watch 配合 flush: 'post'，或者直接在 updated 钩子中操作。更推荐使用 nextTick，因为 nextTick 能确保所有组件都更新完毕，而 updated 只保证当前组件的 DOM 更新完成。
避免在 watch 或 watchEffect 中再次修改会导致渲染死循环的数据 → 如果非改不可，可以通过 nextTick 做一个“延迟”修改，避免在同一个微任务中形成无限递归。

一个完整的执行顺序示例

<script setup>
import { ref, watch, nextTick, onUpdated } from 'vue'

const count = ref(0)

watch(count, () => {
  console.log('watch pre (default)')
})

watch(count, () => {
  console.log('watch post')
}, { flush: 'post' })

onUpdated(() => {
  console.log('updated hook')
})

function change() {
  count.value = 1
  console.log('sync log')
  nextTick(() => console.log('nextTick 1'))
  nextTick(() => console.log('nextTick 2'))
}
</script>

运行 change()，控制台输出顺序为：

sync log
watch pre (default)
watch post
updated hook
nextTick 1
nextTick 2

注意看：同步代码最先执行，紧接着是 pre watch，然后 DOM 更新触发 post 类回调，最后才是 nextTick。多个 nextTick 回调按注册顺序执行，且都在同一批更新后。

理解了这个调度顺序，你就能精准地在正确的时机拿到正确的状态，避免“这个值怎么还没变”的调试事故，也能写出更干净、更高效的响应式逻辑。