Vue 3 的 Patch 过程必须自顶向下，因其依赖递归式树遍历：先判断根节点是否可复用（类型与 key 一致），再逐层更新 props、事件及子节点；该流程契合组件边界、PatchFlag 跳过优化、微任务中断恢复，并确保父子依赖顺序，避免自底向上延迟响应或广度优先破坏样式作用域。
Vue 3 的 Patch 过程是自顶向下的，根本原因在于它采用**递归式树遍历**来比对新旧 VNode 树——从根节点开始，逐层深入子节点，而非一次性展开全部节点再横向比对。这不是设计偏好，而是由虚拟 DOM 的树状结构、响应式更新粒度和 Diff 算法的执行逻辑共同决定的。
为什么必须自顶向下？
因为 Vue 的更新不是“重绘整棵树”，而是“按需修补局部”。Patch 函数接收两个 VNode（n1 和 n2），第一件事就是判断它们是否可复用（isSameVNodeType）：类型一致且 key 相同才进入精细化更新；否则直接卸载旧树、挂载新树。这个判断只能在当前层级做，无法跳过父节点去预判子节点行为。
一旦确认可复用，就自然要往下走：更新当前节点的 props、事件、样式等，再决定是否需要 patch 子节点。而子节点的处理方式（文本 / 单节点 / 多节点数组）又依赖于当前节点的 children 类型，这也要求先完成父级判定，再派发子级任务。
递归比对的真实优势
- 与组件边界天然对齐：每个组件实例对应一棵子 VNode 树，递归 patch 正好契合组件化封装——父组件 patch 时调用子组件的 update 函数，子组件再用自己的 render 生成 nextTree 并递归 patch，形成清晰的调用栈
-
支持按块（Block）跳过静态内容：Vue 3 编译时标记了 PatchFlag，比如
PATCH_KEYED_CHILDREN或TEXT。递归过程中遇到带 flag 的节点，可直接跳过属性全量比对，只处理动态部分，大幅减少计算量 - 便于中断与恢复（Suspense / 异步更新）：递归调用天然支持微任务切片。Vue 的调度器可在某一层 patch 暂停，把控制权交还事件循环，等下次 tick 再继续，这对长列表或深层嵌套组件的流畅更新至关重要
递归带来的代价与应对
递归不是银弹。它的主要短板是调用栈深度和不可控的嵌套层级：
Element Plus Vue3 桌面组件库。在开发 Vue 3.x 页面时调用，使用 Element Plus 组件（如 el-button、el-input、el-form、el-table 等）。
立即学习“前端免费学习笔记（深入）”；
-
栈溢出风险：极端深层嵌套（如 1000 层递归组件）可能触发浏览器栈限制。Vue 本身不主动限制，但实践中应避免无终止条件的递归模板（例如未加
v-if保护的 self-reference） -
难以全局优化中间状态：比如想对整个子树做批量移动操作，递归方式需逐层返回移动指令，不如扁平化索引+一次调度直观。Vue 3 用 最长递增子序列（LIS） 在子节点 diff 阶段弥补这一点——它在递归进入
patchKeyedChildren后，内部转为数组索引运算，不依赖上层递归上下文 -
调试链路长：一个
patch调用可能嵌套十几层，错误堆栈易被淹没。Vue Devtools 通过拦截每次 patch 调用并记录 VNode 路径，把递归过程可视化为可展开的更新树，缓解该问题
对比：为什么不是自底向上或广度优先？
自底向上需要先收集所有叶子节点，再逐级合并差异，这违背了 Vue “响应式驱动更新”的实时性原则——数据变化后，用户期望看到的是根组件状态尽快反映，而不是等整棵树分析完才动第一个 DOM。
广度优先虽利于并发调度，但会破坏父子依赖：比如父节点 class 变更影响子组件的 CSS 作用域，就必须先 patch 父节点才能安全 patch 子节点。递归的深度优先恰好保证了这种执行顺序。
