引用对比发生在 sameVnode 函数的第一层快速判断中，即新旧 VNode 是否“可能是同一个节点”，通过 key 严格相等、tag 一致、基础类型标识匹配四条件全等判定可复用性，否则直接替换。
Vue 的 Patch 过程中，引用对比（reference comparison）是判断节点是否可复用的核心前提，它本身几乎零开销，但一旦误判或缺失，就会引发后续大量不必要的 diff 和 DOM 操作，实际性能损耗远超对比本身。
引用对比发生在 patch 的哪个环节？
它出现在 sameVnode 函数的第一层快速判断中，即新旧 VNode 是否“可能是同一个节点”。Vue 不会直接深比属性或子节点，而是先检查：
-
key 是否严格相等（
===，含null/undefined区分） - 标签名（tag）是否一致
- 是否都是注释节点、是否都是异步占位符等基础类型标识
只有全部满足，才进入后续的 data 更新和 children diff；否则直接判定为不可复用，走替换流程。
为什么引用对比快，却容易成为性能隐患？
JavaScript 中两个对象即使内容完全一样，=== 也返回 false。而 VNode 是每次 render 重新创建的对象，所以：
vue-component-analyzer
下载
递归分析 Vue 项目组件依赖，从入口文件生成组件层级图，支持 Vue 2/3，输出组件名、文件路径和属性。适用于分析组件结构、排查依赖或了解项目架构。
立即学习“前端免费学习笔记（深入）”；
- 没写
:key或 key 值动态生成不稳定（如用index），会导致本该复用的节点被当作全新节点处理 - 组件节点若未显式设置 key，且父级列表顺序变化，可能触发整块子树重建而非移动
- 看似只是“多一次对象创建”，实则引发：子节点全量 diff、事件监听器重绑、过渡动画重置、组件实例销毁重建
如何让引用对比真正发挥效力？
关键不是优化对比逻辑，而是确保它有据可依：
- 列表渲染必须使用稳定、唯一、与数据语义绑定的
key，例如:key="item.id" - 避免用
v-for的index作 key，尤其在插入/删除/排序场景下 - 动态组件切换时，给
<component :is="...">显式加 key，防止状态错乱 - 服务端渲染或 SSR 场景下，确保客户端 hydration 时 key 与服务端输出一致，否则跳过复用直接重建
它不解决所有问题，但决定了 diff 走哪条路
引用对比本身耗时可以忽略不计——它只是几个字段的 === 判断。但它像交通信号灯：绿灯放行，diff 只聚焦局部变更；红灯禁行，整个节点路径就进入高成本重建流程。真正的性能开销不在对比动作，而在它所触发的后续行为选择。
