不建议用 index 作为 key，因其非稳定标识，列表增删或排序时会导致 DOM 复用错位、状态残留和输入框内容错乱；key 应是唯一不变的业务 ID 或生成的 UUID。
不建议用 index 作为 key，根本原因在于它不是数据的稳定标识——一旦列表发生增删、排序或拖拽，index 就会跟着位置变化，而 React 或 Vue 的 diff 算法会误判“谁是谁”，导致 DOM 复用错位、状态残留、输入框内容错乱等真实 Bug。
Key 的本质是“身份凭证”，不是“序号标签”
框架靠 key 来决定：这个新节点，是不是原来那个老节点？如果是，就复用它的 DOM 和内部状态（比如 input 的 value、展开收起状态、定时器）；如果不是，就销毁重建。
index 是动态的：删除第 0 项后，原 index=1 的项变成 index=0，框架看到“新 key=0”对应“旧 key=1”，就会把原第二项当成第一项来复用——但它本不该出现在第一位。
- key 应该像身份证号：不管人站队列第几位，号码不变
- index 像排队编号：插队、离队，编号全变
- 用 index 当 key，等于每次排队都发新号牌，系统认不出谁是同一个人
删减操作中，index key 如何引发状态错乱
假设列表初始为：[{id: 'a', name: '张三'}, {id: 'b', name: '李四'}, {id: 'c', name: '王五'}]，你用 v-for="(item, i) in list" :key="i" 渲染。
点击删除“张三”（即删掉第 0 项），数组变为 [{id: 'b', name: '李四'}, {id: 'c', name: '王五'}]。
此时新列表的 index 是 [0, 1]，对应旧列表的 index=1 和 index=2。框架对比时：
- 新 key=0 → 找旧 key=0（张三）→ 不匹配 → 销毁张三 DOM，新建李四 DOM
- 新 key=1 → 找旧 key=1（李四）→ 匹配 → 直接复用李四 DOM，但把它当成“第二个李四”渲染
- 旧 key=2（王五）没人认领 → 被销毁
问题来了：如果李四那行有个 ，且用户之前输入过“28”，那么复用时这个 input 元素会被保留，value 还是“28”——但此刻它已绑定到“李四”身上，而用户本意只是删张三。更糟的是，若组件内有 ref、定时器或局部 state，它们也会被错误继承。
逆序插入时，DOM 更新效率断崖式下跌
初始列表：['A', 'B', 'C']，用 index 作 key 渲染。
现在在开头插入 'F'，新列表变成：['F', 'A', 'B', 'C']。
diff 过程被迫逐项更新：
- 新 key=0（F）≠ 旧 key=0（A）→ 替换第一个 li 的文本为 F
- 新 key=1（A）≠ 旧 key=1（B）→ 替换第二个 li 的文本为 A
- 新 key=2（B）≠ 旧 key=2（C）→ 替换第三个 li 的文本为 B
- 新 key=3（C）→ 旧列表无 key=3 → 新增一个 li
实际只需新增一个节点，却执行了 3 次 DOM 属性更新 + 1 次插入。若用稳定 id（如 item.id），diff 会立刻识别出 A/B/C 都存在且未变，只新增 F 节点，其余全部复用。
什么情况下用 index 其实勉强可以？
仅当同时满足以下所有条件：
- 列表数据完全静态，永不增删、排序、过滤、搜索
- 每个列表项都是纯展示型（无 input、无 checkbox、无折叠面板、无内部 state）
- 不涉及服务端分页或滚动加载（否则新增页数据会重排 index）
现实中这类场景极少。哪怕只是加个“按时间倒序”按钮，index 就失效了。所以最佳实践始终是：优先使用业务唯一字段（如 user.id、order.sn、todo.uuid）；没有就生成（crypto.randomUUID()），别图省事写 :key="index"。
