虚拟DOM diff通过key属性与节点类型（type）双重校验识别“同一个节点”：仅当二者均相同时才复用节点；无key时退化为顺序比对，易引发状态错乱。
虚拟DOM diff 时怎么识别“同一个节点”
虚拟DOM 的 diff 算法不会靠 HTML 字符串或元素位置来判断节点是否复用，它依赖的是 key 属性 + 节点类型（type）双重校验。没有 key 时，仅靠 type（比如都是 'div'）匹配，容易导致子节点错位、事件监听器丢失、输入框内容异常等隐性 bug。
-
key必须是字符串，且在同级节点中唯一；写成index是常见错误——列表顺序变化时，key不变但实际内容已移位 - 节点
type不只是标签名：函数组件、类组件、内置组件（如Fragment）都算不同type，哪怕渲染结果一样 -
props中的key是唯一参与 diff 指纹计算的字段，其他属性（如id、class）不参与节点复用判定
为什么不能用 HTML 结构当初始指纹
HTML 是静态文本，而虚拟DOM 是运行时生成的 JS 对象树。浏览器解析 <ul><li>a</li><li>b</li></ul> 得到的是真实 DOM 节点，不是 VNode；框架从模板或 JSX 编译出的 VNode 根本不经过 HTML 字符串环节。所谓“HTML 结构”在 diff 过程中根本不存在，更不可能作为指纹源。
- Vue 的 SFC 或 React 的 JSX 编译后直接产出
h()调用，例如h('ul', {}, [h('li', {}, 'a'), h('li', {}, 'b')]) - 即使你手写 VNode 对象，也要显式指定
key，否则框架默认按索引位置“贪心匹配”，这不是稳定策略 - 服务端返回的 HTML 字符串只用于首屏直出（SSR），hydrate 阶段会用客户端生成的 VNode 去“对齐”已有 DOM，对齐依据仍是
key和节点类型，不是 HTML 文本内容
key 为空或缺失时的实际行为
当一组兄弟节点没有 key，或 key 全为 null/undefined，diff 算法退化为“顺序比对”：第 0 个新节点只和第 0 个旧节点比较，依此类推。这在静态列表里看似正常，但一旦插入、删除、排序，就会触发大量无谓的 DOM 移动和重渲染。
- React 控制台会警告：
Warning: Each child in a list should have a unique "key" prop - Vue 3 在开发模式下同样报
[Vue warn]: Missing required prop: "key"类似提示（实际是 runtime 检测逻辑） - Snabbdom 等轻量库更激进：没
key就直接跳过节点复用逻辑，强制销毁重建
哪些场景下 key 的值必须稳定可预测
key 不是越“随机”越好，它必须能稳定映射到数据实体本身。比如用户列表，应该用 user.id，而不是 Math.random() 或 Date.now() —— 后者每次 render 都变，等于告诉 diff “所有节点都是新的”，完全失去复用意义。
立即学习“前端免费学习笔记（深入）”；
- 数组项来自 API 响应：优先用后端返回的唯一 ID 字段（
id、uuid） - 本地生成的数据（如表单临时行）：用
Symbol()或递增数字 + 时间戳组合，确保同一生命周期内不变 - 避免用对象引用（
key={item}）：对象地址每次 render 可能不同，且 JSON.stringify 无法处理循环引用
key 比没有 key 更危险——它让 diff 算法“自信地做错事”，而你很难一眼发现。 
