Vue 列表删掉一行后输入框内容串到别行，是 v-for 的 key 写错了吗？

先给结论：串的不是输入框，是 v-for 的 key 身份错位

2026 年在 Vue 项目里，列表删掉一行后下面几行输入框内容串位，通常不是输入框组件写坏，而是 v-for 的 key 用了数组下标 index。Vue 按 key 判断节点身份，index 会随删除、排序、筛选而改变，原本属于 A 行的 DOM 和组件实例被复用给 B 行，未受控的输入状态就跟着挪位。把 key 换成稳定业务 id 多数能恢复；数据本身没有稳定 id，要先在数据层补上。

为什么删一行会串：虚拟 DOM 复用了什么

Vue 的列表更新不是销毁整段再重建，而是拿新旧节点按 key 做匹配。key 相同就复用原来的 DOM 元素与组件实例，只更新变化部分，这样性能更好。问题出在身份：当 key 是 index，删除第一项后，原 index 0 的节点还在，Vue 认为它还是原来那一项，于是把新数据 B 渲染进 A 的输入框，而输入框里用户已经输入的值、光标位置、第三方组件内部缓存并没有被重置，视觉上就出现下面几行内容串位。

这里要分清两种状态：如果输入值通过 v-model 绑定到了列表数据本身，删除后数据跟着走，一般不会串；容易串的是未受控的 DOM 值、组件内部私有状态、展开或选中缓存。同样一段 v-for，有的项目看着正常，有的项目一删就乱，差别不在框架版本，而在状态放在哪一层。

• 会串：输入框内部自己存值、组件内部维护编辑态、第三方组件缓存了行内索引。
• 较少串：值完全由父级数据驱动，列表项是纯展示组件。
• 容易串：删除中间项后又同时做了排序或筛选，index 身份错位更明显。

列表渲染四项核对法

与其凭感觉改 key，不如按固定顺序核对。下面这套「列表渲染四项核对法」按 2026 年项目交付习惯整理，前两项定身份，后两项定状态归属和兜底手段，跳过任何一项都容易反复返工。

1. 数据有没有稳定唯一 id：先看接口返回字段里有没有业务主键；没有就让后端补，或在数据入口基于业务字段生成稳定标识。不要用每次请求都变的随机值当 id。
2. v-for 的 key 是否用了这个 id：检查是否写成 :key 绑定 index 或省略 key。中间插入、删除、排序、筛选四类操作都会让 index 身份变化。
3. 输入态和展开态存在哪：值绑在列表数据上，还是留在组件内部、DOM 上。留在内部的要评估删除行后是否需要随行销毁。
4. 是否需要强制重建：只有切换数据源要清空内部缓存等少数场景才用 key 变化强制重建组件。它是兜底，不是常规写法，整项重建有性能代价。

四步里第一步经常被跳过。经验上，列表串行问题里约六成到七成能靠「补稳定 id + 改 key」解决，剩下的才需要调整状态归属或组件重建策略。做到什么算合格：删除中间任意一项后，剩余行的输入值、展开态、选中态都不跟着换位。

index 作 key 和业务 id 作 key，差在哪

两种写法都能跑，差别在身份是否稳定和更新代价。下面按适用对象、常见风险、经验成本三个维度对比，数字为经验区间，实际以项目复杂度为准。

• index 作 key：适合纯静态展示、只在末尾追加且不再排序的短列表；风险是增删排序后状态串位；代码成本低，但返工成本常见区间约 0.5 到 2 个工作日。
• 业务 id 作 key：适合可增删、可编辑、可排序、可筛选的列表；风险是要保证 id 稳定，否则组件会频繁重建；前期多花一点时间整理数据，后续改稿和联调更省。
• 随机数作 key：看起来唯一，实际上每次渲染都变，等于让 Vue 整列表重建，列表项较重时会出现输入丢焦、动画跳变，不建议作为常规做法。
• 复合 key：当业务上确实没有单一主键时，可用业务字段组合拼出稳定值；组合字段要真正唯一，否则等于没换。

判断好坏不看代码行数，而看四个操作：中间删除、头部插入、倒序排列、条件筛选。四项做完状态不串，才说明 key 选对了。

交付现场：一个后台表单列表删行后校验错位

在一个后台表单项目里，约束很常见：两周排期，列表字段由后端拼接返回，前端先按数组下标渲染，输入框用的是第三方组件的内部值。开发阶段只测了首屏和末尾追加，看上去正常。联调时删除第二行，第三行的校验提示和输入值跟着上移，提交后数据错位，排查加返工常见区间约 1 到 2 个工作日。做法是让后端补业务主键，前端把 key 换成主键，并把编辑态收回到列表数据里，之后删除、排序、筛选都不再串。这个代价说明，key 不是样式细节，而是列表身份契约。

常见坑与验收口径

下面这些坑在 2026 年的项目里仍会遇到，按出现频率和影响排序。验收时不用通读代码，按操作路径走一遍即可。

• 用 index 还加过渡动画：删除后动画会挂在错误的节点上，出现闪动或错位；先修 key，再调动画。
• 列表项组件内部 watch index：行内组件通过下标判断自己是不是第一项时，删除后判断会错；应改为传业务 id 或布尔标记。
• 筛选后不重置输入态：筛掉的行如果被复用，输入框里可能残留上一次的值；筛选属于身份变化场景，要按新列表重建或按 id 匹配。
• 只测首屏和追加：这是串行问题漏到线上的常见原因，测试用例应覆盖中间删除、头部插入、倒序、筛选四类操作。

验收标准可以写三条：删除中间项后其余行状态不位移；排序和筛选后不出现上一组输入值；提交的数据与当前展示行一一对应。三条都过，才算列表渲染合格。

适用与不适用边界

列表渲染的 key 策略不是越复杂越好，要和列表生命周期匹配。只要列表会发生中间增删、排序或筛选，就建议用稳定业务 id 作 key；如果列表一次渲染后不再变化，index 的负面影响很小，但仍建议统一用 id，以免后期改需求时踩坑。

• 适合优先用业务 id：可编辑表格、审批流列表、购物车、聊天记录、带展开行的树形列表。
• 可以用 index 的窄场景：数据来自静态配置、只渲染一次、不含用户输入和内部状态。
• 不必上额外方案的场景：列表规模很小且只做展示时，不需要引入虚拟滚动或复杂 key 生成逻辑。
• 不适用：为了掩盖 key 问题而整列表强制重建，列表项较重时会造成输入丢焦和明显卡顿。

常见问题

Vue 里 v-for 不加 key 会怎样？

不加 key 时 Vue 默认就地复用，增删顺序变化时同样可能串状态；key 的作用是给节点稳定身份，能加就加。

用 index 当 key，列表只追加不删除会有问题吗？

只在末尾追加、不排序不筛选时，index 与数据顺序一致，问题不易出现；一旦中间插入或删除，身份就会错位。

输入框已经 v-model 绑定数据了，为什么还串？

绑定到数据上的值不会串，串的通常是组件内部私有状态、未受控 DOM 值或第三方组件缓存，需要把状态提到数据层。

换成唯一 id 后列表更新变慢，是 key 的问题吗？

通常不是 key 本身，而是 id 不稳定导致组件频繁重建，或列表项过重；先确认 id 是否每次请求都变，再考虑虚拟滚动。

列表数据没有唯一 id，2026 年常见做法是什么？

可让后端补主键，或在数据入口基于业务字段生成稳定组合值；不建议用随机数，随机会让每次渲染都整列表重建。

行动上，先找列表数据里的稳定主键，把 v-for 的 key 换过去，再用中间删除、头部插入、倒序、筛选四类操作跑一遍验收。如果数据暂时没有主键，就让接口补，不要在前端用下标硬撑。适用边界是：会变的列表用业务 id，只渲染一次的静态列表可放宽，但别把随机数当 key。