本文详解 react 状态数组删除操作中常见的“删错项”问题，核心在于正确使用函数式 setstate 获取最新状态，并区分受控（value）与非受控（defaultvalue）输入框对渲染一致性的影响。
在 React 中，安全、可靠地从状态数组中删除指定索引的元素，看似简单，却极易因状态更新异步性、闭包捕获旧值或表单控件模式误用而引发隐蔽 bug——例如点击删除第 2 项，实际却移除了最后一项。根本原因有二：状态读取过时 和 组件受控性不一致。
✅ 正确做法：始终使用函数式更新（Functional Update）
原始代码中 delData 直接解构 gridData.data，但 gridData 是上一次渲染的快照，若在多次快速调用 delData 或与其他状态更新竞争时，gridData.data 可能已滞后。应严格通过 setState(prev => ...) 获取最新状态：
const delData = (ndx) => {
setGridData((prevGridData) => {
// 基于最新 prevGridData.data 进行过滤，确保数据新鲜
const updatedData = prevGridData.data.filter((_, index) => index !== ndx);
return { ...prevGridData, data: updatedData };
});
};⚠️ 注意：filter 比 splice 更符合函数式编程原则——它不修改原数组，返回新数组，避免副作用，也天然规避了 splice 的可变性风险。
❌ 错误根源：defaultValue 导致非受控组件行为
当使用 defaultValue 时，React 将 视为非受控组件：其初始值由 defaultValue 设定，但后续值由 DOM 自行管理，React 不再干预。此时若数组状态更新后重新渲染，React 会复用原有 DOM 节点（因 key 缺失或未正确设置），导致 defaultValue 不再生效，视觉上出现“删除错位”——看似删了索引 1，实则因 DOM 复用，最后渲染的 input 被错误保留。
而 value={r.description} 将其变为受控组件：输入值完全由 React 状态驱动，每次渲染都强制同步 DOM，确保 UI 与 gridData 状态严格一致。
✅ 正确示例（含 key 与受控输入）：
const buildRows = () => {
return gridData.map((r, rndx) => (
<div key={rndx} style={{ display: "flex", margin: "4px 0" }}>
<button onClick={() => delData(rndx)}>Delete #{rndx + 1}</button>
<input
value={r.description}
readOnly
style={{ marginLeft: "8px", padding: "4px" }}
/>
</div>
));
};? 关键点：key={rndx} 显式绑定索引（仅当数据顺序稳定且无动态插入时适用；更佳实践是使用唯一 ID 作为 key）；value 确保受控，杜绝 DOM 复用歧义。
? 最佳实践总结
- 永远优先用 filter() 删除数组项，而非 splice() + 展开运算符，兼顾不可变性与可读性；
- 所有状态更新必须用函数式 setState(prev => ...)，尤其涉及依赖前一状态的逻辑；
- 表单输入务必使用 value + onChange（受控），禁用 defaultValue 配合动态列表，否则将破坏 React 的协调（reconciliation）机制；
- 为列表项提供稳定、唯一的 key（如数据 id），避免仅依赖索引，防止重排时 UI 错乱。
遵循以上原则，即可彻底规避“删错项”这类典型 React 状态陷阱，构建健壮、可预测的数据交互逻辑。
