Diff算法核心是同层比较与key驱动的节点复用：仅对比同级节点以保障O(n)复杂度，key作为唯一标识决定节点是否可复用，错误使用会导致输入错位、动画卡顿、滚动跳变等实际问题。
Diff 算法不是“比完就完”的黑盒，它直接决定你写的 v-for 或 map 列表更新时，输入框内容会不会错位、动画会不会卡顿、滚动位置会不会跳——关键就在同层比较逻辑和 key 的使用是否合理。
为什么同层比较是硬约束，不是可选项
框架（Vue 2/3、React）的 Diff 实现默认跳过跨层级节点对比。比如旧树中 div > ul > li，新树变成 div > section > ul > li，ul 节点不会被复用，而是整段销毁重建。
这不是偷懒，是性能取舍：跨层级移动在真实业务中占比极低，但暴力遍历整棵树的时间复杂度会从 O(n) 崩到 O(n³)。
常见误判场景：
立即学习“前端免费学习笔记（深入）”；
- 用
v-if和v-else切换不同结构的列表容器（如ul↔ol），导致子节点全部失活重挂 - 在列表项内部动态插入/删除父级 wrapper（比如加一层
div包裹li），触发整组子节点重新生成 - 服务端渲染（SSR）后客户端 hydration 时，DOM 结构与 VNode 树不严格对齐，
patch过程直接 fallback 到全量替换
key 写错的三种典型表现
key 不是锦上添花的优化项，它是 Diff 判断“同一个节点”的唯一依据。写错就会让框架“认不出老朋友”。
错误模式与后果：
- 用数组索引
:key="index"：列表增删时 key 错位，输入框绑定值、焦点、滚动状态全部错乱 - 用随机数或
Date.now()：每次渲染 key 都变，节点永远不复用，性能归零 - 多个节点用了相同
key（比如都写死为"item"）：框架只保留最后一个，其余被静默丢弃
正确做法只有一条：key 必须是稳定、唯一、与业务数据强绑定的字段，例如 :key="item.id"。即使 id 是后端返回的临时 uuid，也比索引可靠。
Vue 的 updateChildren 双端对比怎么跑的
当两个 vnode 列表都有 key 且长度不同时，Vue 2/3 的 updateChildren 会启动双端指针算法，不是从头到尾挨个比，而是四点并发判断：
- 旧头 vs 新头 → 相同则更新并推进头指针
- 旧尾 vs 新尾 → 相同则更新并回退尾指针
- 旧头 vs 新尾 → 相同说明节点被移到末尾，执行移动操作
- 旧尾 vs 新头 → 相同说明节点被移到开头，执行移动操作
一旦这四组都不匹配，就查哈希表（基于 key 构建的 oldKeyToIdx 映射）找可复用节点；找不到就新建，找得到就移动。最后收尾处理剩余节点：旧的多出来就删，新的多出来就增。
注意：这个过程完全依赖 key 存在。没 key 就退化成朴素遍历，O(n²) 比较，且无法移动节点，只能删+增。
React 的 reconcileChildrenArray 和 Vue 本质差异在哪
React 不叫 “Diff”，叫 “Reconciliation”，但它底层仍是同层比较 + key 驱动。关键区别在于策略粒度：
- React 把列表 diff 交给
reconcileChildrenArray，但它的key匹配是线性扫描（未建哈希表），最坏 O(n²)，靠shouldComponentUpdate或React.memo提前拦截 - Vue 在 patch 阶段就建好
key → index映射，查找是 O(1)，移动逻辑更激进（比如insertBefore直接挪 DOM） - React 更倾向“不可变更新”，节点复用率略低于 Vue；Vue 更倾向“就地复用”，但对
key正确性更敏感
所以你在面试里听到“React Diff 是深度优先，Vue 是双端对比”，其实是简化说法——两者都做同层比较，差别在子节点列表的匹配策略和副作用处理时机。真正踩坑的，永远是那个漏掉 key 或写错 key 的人。
