很多人刚开始接触前端组件开发时都会遇到一个很尴尬的局面业务需求明明只是改一个表格但改着改着就把项目里的 Table 组件给“掀翻”了。就拿自定义 table 组件里“节点更新”和“节点删除”这个需求来说看接口文档、翻源码、搜社区到处都是零散的片段——有人在说 key 的重要性有人在讲写数据之后视图不刷新还有人因为删除后选中状态错乱一个下午没下班。这篇文章就把这部分内容一次性说透我不会讲那些“你用 Vue 就用 splice、用 React 就用 setState”这种一句废话带过的教程而是从“为什么要这么做”“不这么做会怎样”“实测中你会遇到哪些意外”三个角度往下拆给出能直接复现的代码、思路和避坑清单。先交代清楚这篇文章解决的具体问题第一自定义 table 组件中单行节点新增或修改后视图如何正确、高效地更新第二删除一行时从数据源到视图、再到选中态和索引关联整条链路应该怎么处理第三实操中常见的“数据变了视图不动”“删除错行”“复选框状态混乱”等问题的根因和排查方式。无论你是在自研后台管理系统还是在封装公司内部的中后台组件库这些内容应该都能帮上忙。1. 为什么要自己写 table 组件从“不满意”开始1.1 现成组件库很强大但业务总有它想不到的场景先说个现实情况Element、Ant Design、Naive 这些组件库的 table 确实很成熟常规的需求——排序、筛选、分页、固定列、树形数据开箱即用。可一旦进入真实业务总有那么几个需求让你“血压升高”。我印象最深的一次是接手一个数据上报平台表格里某一行需要通过定时器实时展示任务进度百分比同时轮询过程中要更新行内的状态文案、进度条颜色、甚至当前节点的耗时。用现成组件库的默认 API 去做每一次更新都得重组整个 dataSource 数组数据量大了之后页面明显卡顿用户体验也很一般。另一个高频场景是行内编辑点击某行“编辑”按钮这一行切换成可输入状态修改某个字段后点击“保存”只更新那一行的数据。这时候你用组件库默认的整表渲染机制数据源一变所有行都会重新走一遍 diff性能差点倒还能忍关键是行内编辑状态、单元格里的临时值、校验状态都很容易被“重置”掉搞得用户刚输入一半的内容突然没了。自定义 table 组件的价值就在这里你不需要接管所有行而是精确控制哪一个节点需要更新、哪一个节点需要保留原样。1.2 自定义组件的第一条分水岭先想清楚“数据驱动”这回事不管你用什么框架自定义 table 组件的精髓都是同一句话视图是数据的映射更新和删除的本质是对数据源的操作而不是直接操作 DOM。这句话听起来像是废话但我发现很多初学者在做“删除行”功能时第一反应是去操作 DOM——把对应的tr移除掉这是完全走偏了。正确的做法是维护一个tableData数组每一行对应一个对象对象里存这一行展示所需的所有字段。视图层通过v-forVue或者mapReact把数组渲染成行。当数据源发生变化框架会通过 diff 算法去检查新旧节点之间的差异只更新发生变化的行。这个“只更新变化的部分”正是虚拟 DOM 的厉害之处也是我们自定义组件的底气所在。自定义组件还有一个优势是可控性。你可以决定“更新”的粒度——是整行替换还是某个单元格局部更新你可以决定“删除”之后要不要保留索引占位要不要触发过渡动画。这些在现成组件库的 API 里通常要通过各种 hack 才能实现自己封装反而是更清楚的选择。1.3 Hello Table一个最小可运行版本我们用一个最小化的例子来建立直观感受。假设现在要做一个简单的任务列表每行有任务名、状态、操作按钮。数据定义如下const tableData ref([ { id: 1, name: 任务一, status: pending }, { id: 2, name: 任务二, status: pending }, { id: 3, name: 任务三, status: done } ]);模板里遍历渲染table thead tr thID/th th任务名/th th状态/th th操作/th /tr /thead tbody tr v-forrow in tableData :keyrow.id td{{ row.id }}/td td{{ row.name }}/td td{{ row.status }}/td td button clickupdateRow(row)更新/button button clickremoveRow(row.id)删除/button /td /tr /tbody /table这里的:keyrow.id是整个组件的命脉它决定了更新和删除时框架到底“认不认得出”哪一行是原来的哪一行。先把这句话记在心里后面会反复提到它。2. 节点的正确打开方式不是 HTML 节点是“数据节点”2.1 从数据到视图的映射每次渲染都是一次“翻译”要深入理解节点更新首先得建立一个概念当你写v-for或者map时你并没有描述“页面上有哪些tr”你描述的是“数据数组有哪些元素每个元素对应一个tr”。至于这个tr从无到有、从旧到新、从有到无框架会帮你完成。这意味着更新节点 更新数据源中对应的那一项删除节点 从数据源中移除那一项。这句话看似简单但绝大部分 bug 都出在“我明明更新了数据源怎么界面还是老样子”或者“我明明删了数据怎么界面上少了两行”这类问题上。问题的根源往往不在于你的操作意图而在于你操作数据的方式没能触发框架的响应机制或者数据源中的 key 标识混乱了。2.2 为什么说 key 是表格的“身份证”在 Vue 3 和 React 中key的作用分别是这样Vue 的 diff 算法在对比新旧v-for生成的虚拟节点列表时会优先通过key来判断“哪些旧节点可以复用、哪些是新增、哪些是删除”React 同样在协调reconciliation阶段利用key来识别列表项。如果表格每行没有稳定的唯一标识渲染后 DOM 的“身份”就是它的位置。比如你删掉第二行第三行会顶上来但框架会认为“原来的第三行变成了第二行”所以它会把原来第三行的 DOM 拿来改内容而不是老老实实把第二行卸载掉。绝大多数情况下这种“复用”不影响正确性——反正内容会更新成最新数据。但一旦某一行内部有本地状态比如行内编辑框的未提交内容、展开的行、单元格组件的临时状态这种“身份错乱”就会带来真实可见的 bug你删了 A 行B 行的展开状态却消失了你更新了 C 行D 行的表单输入内容却被重置了。所以第一原则每一行都要有稳定的、业务上唯一的key千万不要用数组下标当key。数组下标的 key 本质上就等于没有 key因为它在删除、插入后无法维持“同一身份”。2.3 按 id 去重而不是按下标一个真实事故有次我在封装组件时偷了个懒用index做了 key。当时觉得“反正是静态列表不会删也不会加”。结果产品经理的需求第二天就到了支持批量删除。批量删除之后表格行倒是减少了但第三行的状态图标全乱了——因为复用的是旧节点的 DOM而旧节点的状态类名还留在原地。排查过程其实不复杂我在删除逻辑里打了 console发现数据源内容是正确的那就基本锁定是渲染层复用出了问题。把 key 从index改成row.id之后问题立刻消失。那次之后我就给自己定死了规矩没有唯一 id 的表在拿到接口数据的第一时间就要主动添加一个_rowKey字段宁可多占点内存也不能让渲染层“瞎认亲”。3. 改了一行数据视图没反应更新链路上的三个“鬼门关”3.1 鬼门关一直接改 props等于给组件递了份复印件自定义 table 组件通常接收外部传入的数据比如props.tableData。很多新手写“更新”操作时直接在组件内部执行props.tableData[index].status done;这句话在 Vue 3 里通常不会直接生效因为直接修改 props 对象在开发模式下会有警告而且它会让数据流变得不可追踪。在 React 里就更不推荐了props 应该是只读的直接修改等于破坏了单向数据流。正确的更新方式应该是“事件上抛”组件内部通过emit告诉父组件“我要改这一行”然后由父组件把新的数据源传给子组件。也就是说数据源是唯一的更新动作应该发生在数据源的主人那里。这个模式虽然多写了几行代码但数据始终只有一个“权威来源”排查问题时你只需要看两处父组件的数据操作和子组件的渲染映射不用到处找是谁偷偷改了什么。3.2 鬼门关二把数组 push 成了堆setter 监听不到更新某个节点时有人喜欢这样写const newData tableData.value; newData[index].name 新名字;直接改数组某一项的话如果是 Vue 2数组的索引变更无法被Object.defineProperty拦截到视图自然不更新Vue 3 使用 Proxy 之后这个限制好了一些但如果嵌套层数过深有时也会遇到潜在问题。React 就更直接了——你改了 state 里数组的内存对象但没有调用setStateReact 根本不知道数据变了因为引用没变。这里有一个我觉得比较牢固的判断标准把“数据更新”想成一次“换新”而不是“抹改”。当你需要更新数组中的某一个 item 时最保险的方式是创建一个新的数组新数组里对应位置放一个新的对象。以 Vue 3 为例const index tableData.value.findIndex(row row.id targetId); if (index -1) { const newArray [...tableData.value]; newArray[index] { ...newArray[index], name: 新名字 }; tableData.value newArray; }这段代码做的事是先复制旧数组浅拷贝开销很小再替换对应位置为新对象最后整体赋值。区别在于数组的引用变了框架能明确感知“数据源整体变化了”从而触发渲染流程。虽然感觉上绕了一点但换来的是稳定性和可预测性。3.3 鬼门关三对象新增属性响应系统直接“失明”还有一个高频问题表格里每个对象一开始只有name和status你在更新时突然想加一个remark字段然后界面上怎么都不展示。原因在于 Vue 3 的响应式系统基于 Proxy虽然动态新增属性可以触发响应但如果你用的是Object.assign把整个对象替换掉、或者某些框架内部对对象做了冻结新增属性不一定被“观察”到。保险的做法是更新一行数据时把该行的对象也“换新”而且是完整地把所有要展示的字段都放进去。哪怕新加字段的值为空字符串也要显式带上。这样做有一个额外好处组件渲染的时候不会因为字段缺失报错类型也一目了然。newArray[index] { id: oldRow.id, name: oldRow.name, status: running, remark: 新增字段检查 };3.4 更新之后的渲染顺序diff 算法在 table 场景下的表现聊完三个鬼门关我们再往底层看一眼当你用“新数组替换旧数组”的方式更新数据后Vue/React 的渲染层会发生什么。以 Vue 3 为例组件会触发重新渲染然后对新旧虚拟节点做 patch。因为每个节点的 key 是稳定的iddiff 算法会快速匹配“哪些节点没变、哪些节点变了”。没变的直接跳过只有内容变化的那一行才会重新渲染并更新 DOM。这也解释了为什么key如此重要如果没有 keydiff 算法只能用“逐个比较”的方式把所有节点都过一遍遇到顺序变化还可能整块替换。有了稳定的 key它就能做到“按图索骥”——只处理真正有变化的那一行。自定义 table 在大数据量下是否卡顿很多时候拼的就是 key 的设计和更新时是否做到了“局部最小化”。4. 删除节点不只是 splice 这么简单4.1 删除的核心原则改数据不是动 DOM删除操作的核心逻辑很简单根据某个唯一标识把数据源数组中对应的那一项过滤掉。这里我推荐用filter而不是splice因为filter更符合“数据不可变”的操作理念function handleDelete(rowId) { tableData.value tableData.value.filter(row row.id ! rowId); }这一行代码完成了删除的全部核心工作数据源中移除该行渲染层感知到数组引用和内容变化自动把对应的tr移除。不要在这里去操作 DOM不要尝试手动抓document.querySelector去删节点——那是一条死路删完之后你还需要自己维护行号和 DOM 的对应关系相当于绕回了 jQuery 时代。4.2 踩过的坑删完数据之后复选框状态全乱了如果你做过带多选功能的表格应该能理解这种痛。表格第一列有一排复选框用户勾选了几行然后执行删除。很多人的第一版代码是这样的复选框选中的状态存在组件的本地selectedRows数组里用户勾选时把row对象推进去删除时从数据源中移除然后就……出问题了。问题出在两处。第一row对象是引用如果你在别处修改了对象内容数组里存的旧引用可能拿到的是脏数据第二删除之后selectedRows数组没有同步清理里面存了一堆“幽灵行”这些行在界面上已经不存在了但勾选计数、批量操作时会莫名其妙地把它们算进去。我的处理方式是不要存整行对象只存 id 数组。需要读取选中行的数据时再根据 id 去数据源里查找。删除后同步过滤掉已删除的 idconst selectedIds ref([]); function handleDelete(rowId) { tableData.value tableData.value.filter(row row.id ! rowId); selectedIds.value selectedIds.value.filter(id id ! rowId); }另外还有一个细节批量删除时最好在删除之前先拿到要删除的 id 集合然后一次性完成过滤和清除避免在循环里一边删除一边改索引。4.3 带过渡动画的删除让用户看到“发生了什么”从交互体验上来说直接“唰”地一下让一行消失总有种生硬感。但加删除动画其实是个“技术活”因为核心矛盾在于数据已经从数组里移除了可 DOM 还希望短暂地“存在一会儿”来完成淡出/收起动画。我的经验是用一个removingIds集合来记录“正在退场”的行。删除点击时不立即改数据源而是先把该行加入退场集合触发一个过渡动画动画结束后再真正从数据源移除并把 id 从退场集合里清理掉。伪代码逻辑如下const removingIds ref(new Set()); function removeWithAnimation(rowId) { removingIds.value.add(rowId); setTimeout(() { tableData.value tableData.value.filter(row row.id ! rowId); removingIds.value.delete(rowId); }, 300); }渲染时需要判断该行是否在退场集合中并把leaving类加上tr v-forrow in tableData :keyrow.id :class{ leaving: removingIds.has(row.id) } ... /tr配合 CSS 过渡或动画就能实现淡出高度收缩的效果。这段逻辑让删除有了一次平滑的“告别仪式”用户也能直观地感知数据确实被移除了。4.4 二次确认与撤销生产环境必须考虑的两个细节删除是破坏性操作生产环境的表格几乎都要求二次确认。这个需求本身不难但有个小地方容易忽略如果删除的是一行带子节点的数据或者删除会影响后续统计的节点一定要在确认弹窗里把“删了之后会造成什么影响”说清楚最好标注节点名称和数量。再说撤销。以我的经验撤销功能是删除操作里用户体验提升最明显、但成本也不算高的一个需求。实现思路并不复杂删除前把这一行对象深拷贝一份存到一个trashStack数组里然后提供“撤销”按钮点击时把对象插回原来的位置或者插入到末尾。const trashStack ref([]); function handleDelete(rowId) { const index tableData.value.findIndex(row row.id rowId); if (index -1) { trashStack.value.push({ index, row: JSON.parse(JSON.stringify(tableData.value[index])) }); tableData.value tableData.value.filter(row row.id ! rowId); } } function undo() { const last trashStack.value.pop(); if (last) { tableData.value.splice(last.index, 0, last.row); } }当然深拷贝用JSON.parse(JSON.stringify())只适用于纯数据对象如果里有函数、Date、RegExp 之类的类型建议用更健壮的深拷贝方案。核心思路是删除不是“彻底销毁”而是先“暂存”一个恢复入口。5. 实测复盘组件库里见过但你没深究的边界情况5.1 快速删除时 index 错位真凶往往是“异步闭包”有一种 bug 表现比较诡异用户快速连续点击多行的“删除”按钮结果删除的行和目标行总是对不上。比如点击第三行的删除结果第五行没了。这种问题大概率出在异步闭包里的 index 捕获上。常见写法是async function removeRow(row, index) { const res await confirmDelete(row.id); tableData.value.splice(index, 1); // index 是旧下标 }看起来没什么问题但假如用户在第一行删除的确认还没返回时第二行就发起了删除请求。等第一个确认返回时数据源可能已经因为第二个删除操作减少了行此时旧 index 已经失效再拿它去 splice删掉的自然不是预期的行。我在实际封装时推荐的姿势是永远不要拿“旧的 index”去删除数据而是始终靠唯一 id 定位行。上面filter的写法天然免疫这个问题因为它不依赖 index。如果某些场景必须用到 splice比如需要控制插入位置那也应该在异步操作返回后重新根据 id 查找最新的 index再执行删除。5.2 大数据量下的更新卡顿分片更新思路与时机表格数据量到了一定级别比如几千行以上频繁整表刷新会明显感觉卡顿。我在之前的一个调度任务表格里测过5000 行左右时全量替换 dataSource渲染时间能到 400ms 以上这种体验在交互里不可接受。优化的方向有几个局部更新只更新变更的那一行而不是每次倒腾整个数组。在 Vue 3 里可以通过ref的嵌套 明确指定行 id 实现。虚拟滚动只渲染可视区域内的行。这是数据量极大时的终极方案实现复杂度也高一些但收益巨大。分片更新如果确实需要一次更新很多行把数组拆成几个小批次每批次之间用requestAnimationFrame或setTimeout隔开避免一次渲染阻塞主线程太久。async function updateRowsByChunk(newRows, chunkSize 100) { for (let i 0; i newRows.length; i chunkSize) { const chunk newRows.slice(i, i chunkSize); // 将 chunk 更新进数据源 mergeRows(chunk); await nextTick(); // 等待当前批次渲染完成 } }不过分片更新的体验不是所有场景都适用——如果用户期待的是“一次性全部看到最新结果”分片反而会造成视觉上的撕裂感。我是倾向于在“定时轮询更新状态列”这种场景用分片普通用户主动触发的更新还是保持全量替换就行。5.3 跨项目迁移时的反思不同框架下的差异与一致性策略最后聊一段个人体会。我做过从 Vue 2 迁移到 Vue 3、以及从 jQuery 时代的表格迁移到 React 表格的项目最大的感受是“数据驱动”的理念是共通的差异只在具体写法上。Vue 2 的响应式有天然的缺陷——数组索引变动、新增属性都不触发更新所以在迁移时必须把所有“靠触发魔法”的代码改成“显式替换引用”的写法也就是前文反复提到的“新数组替换旧数组”。Vue 3 因为 Proxy 的增强很多旧写法能跑通了但为了保持组件行为的一致性我仍然建议采用不可变数据的风格。React 这边update 和 delete 都必须走setState这条显式路径反而逼着你把逻辑写得更清晰。还有一点值得说无论哪个框架表格组件的对外 API 设计比内部实现更影响后续维护。比如我自己的习惯是把updateRow(newRow)、deleteRow(id)、clearSelections()这些方法通过expose或者组件实例暴露出去让父组件调用而不是让父组件直接传一个巨大且频繁变化的数据源。这样组件的边界清晰各自负责什么一目了然。通过这些边界情况的复盘能明显感觉到写自定义 table 组件的难度不在单个功能点而在“数据、渲染、交互、性能”四者的协同一致。每一次更新和删除背后都牵动着数据的权威性、diff 的复用策略、用户的感知体验。把这些基础链路摸熟了再去封装自己的组件库心里会踏实得多。 
长河君 · 2026/9/15 4:43:04 · 阅读 1.2k 自定义Table组件节点更新与删除：从key到diff算法的完整避坑指南
很多人刚开始接触前端组件开发时都会遇到一个很尴尬的局面业务需求明明只是改一个表格但改着改着就把项目里的 Table 组件给“掀翻”了。就拿自定义 table 组件里“节点更新”和“节点删除”这个需求来说看接口文档、翻源码、搜社区到处都是零散的片段——有人在说 key 的重要性有人在讲写数据之后视图不刷新还有人因为删除后选中状态错乱一个下午没下班。这篇文章就把这部分内容一次性说透我不会讲那些“你用 Vue 就用 splice、用 React 就用 setState”这种一句废话带过的教程而是从“为什么要这么做”“不这么做会怎样”“实测中你会遇到哪些意外”三个角度往下拆给出能直接复现的代码、思路和避坑清单。先交代清楚这篇文章解决的具体问题第一自定义 table 组件中单行节点新增或修改后视图如何正确、高效地更新第二删除一行时从数据源到视图、再到选中态和索引关联整条链路应该怎么处理第三实操中常见的“数据变了视图不动”“删除错行”“复选框状态混乱”等问题的根因和排查方式。无论你是在自研后台管理系统还是在封装公司内部的中后台组件库这些内容应该都能帮上忙。1. 为什么要自己写 table 组件从“不满意”开始1.1 现成组件库很强大但业务总有它想不到的场景先说个现实情况Element、Ant Design、Naive 这些组件库的 table 确实很成熟常规的需求——排序、筛选、分页、固定列、树形数据开箱即用。可一旦进入真实业务总有那么几个需求让你“血压升高”。我印象最深的一次是接手一个数据上报平台表格里某一行需要通过定时器实时展示任务进度百分比同时轮询过程中要更新行内的状态文案、进度条颜色、甚至当前节点的耗时。用现成组件库的默认 API 去做每一次更新都得重组整个 dataSource 数组数据量大了之后页面明显卡顿用户体验也很一般。另一个高频场景是行内编辑点击某行“编辑”按钮这一行切换成可输入状态修改某个字段后点击“保存”只更新那一行的数据。这时候你用组件库默认的整表渲染机制数据源一变所有行都会重新走一遍 diff性能差点倒还能忍关键是行内编辑状态、单元格里的临时值、校验状态都很容易被“重置”掉搞得用户刚输入一半的内容突然没了。自定义 table 组件的价值就在这里你不需要接管所有行而是精确控制哪一个节点需要更新、哪一个节点需要保留原样。1.2 自定义组件的第一条分水岭先想清楚“数据驱动”这回事不管你用什么框架自定义 table 组件的精髓都是同一句话视图是数据的映射更新和删除的本质是对数据源的操作而不是直接操作 DOM。这句话听起来像是废话但我发现很多初学者在做“删除行”功能时第一反应是去操作 DOM——把对应的tr移除掉这是完全走偏了。正确的做法是维护一个tableData数组每一行对应一个对象对象里存这一行展示所需的所有字段。视图层通过v-forVue或者mapReact把数组渲染成行。当数据源发生变化框架会通过 diff 算法去检查新旧节点之间的差异只更新发生变化的行。这个“只更新变化的部分”正是虚拟 DOM 的厉害之处也是我们自定义组件的底气所在。自定义组件还有一个优势是可控性。你可以决定“更新”的粒度——是整行替换还是某个单元格局部更新你可以决定“删除”之后要不要保留索引占位要不要触发过渡动画。这些在现成组件库的 API 里通常要通过各种 hack 才能实现自己封装反而是更清楚的选择。1.3 Hello Table一个最小可运行版本我们用一个最小化的例子来建立直观感受。假设现在要做一个简单的任务列表每行有任务名、状态、操作按钮。数据定义如下const tableData ref([ { id: 1, name: 任务一, status: pending }, { id: 2, name: 任务二, status: pending }, { id: 3, name: 任务三, status: done } ]);模板里遍历渲染table thead tr thID/th th任务名/th th状态/th th操作/th /tr /thead tbody tr v-forrow in tableData :keyrow.id td{{ row.id }}/td td{{ row.name }}/td td{{ row.status }}/td td button clickupdateRow(row)更新/button button clickremoveRow(row.id)删除/button /td /tr /tbody /table这里的:keyrow.id是整个组件的命脉它决定了更新和删除时框架到底“认不认得出”哪一行是原来的哪一行。先把这句话记在心里后面会反复提到它。2. 节点的正确打开方式不是 HTML 节点是“数据节点”2.1 从数据到视图的映射每次渲染都是一次“翻译”要深入理解节点更新首先得建立一个概念当你写v-for或者map时你并没有描述“页面上有哪些tr”你描述的是“数据数组有哪些元素每个元素对应一个tr”。至于这个tr从无到有、从旧到新、从有到无框架会帮你完成。这意味着更新节点 更新数据源中对应的那一项删除节点 从数据源中移除那一项。这句话看似简单但绝大部分 bug 都出在“我明明更新了数据源怎么界面还是老样子”或者“我明明删了数据怎么界面上少了两行”这类问题上。问题的根源往往不在于你的操作意图而在于你操作数据的方式没能触发框架的响应机制或者数据源中的 key 标识混乱了。2.2 为什么说 key 是表格的“身份证”在 Vue 3 和 React 中key的作用分别是这样Vue 的 diff 算法在对比新旧v-for生成的虚拟节点列表时会优先通过key来判断“哪些旧节点可以复用、哪些是新增、哪些是删除”React 同样在协调reconciliation阶段利用key来识别列表项。如果表格每行没有稳定的唯一标识渲染后 DOM 的“身份”就是它的位置。比如你删掉第二行第三行会顶上来但框架会认为“原来的第三行变成了第二行”所以它会把原来第三行的 DOM 拿来改内容而不是老老实实把第二行卸载掉。绝大多数情况下这种“复用”不影响正确性——反正内容会更新成最新数据。但一旦某一行内部有本地状态比如行内编辑框的未提交内容、展开的行、单元格组件的临时状态这种“身份错乱”就会带来真实可见的 bug你删了 A 行B 行的展开状态却消失了你更新了 C 行D 行的表单输入内容却被重置了。所以第一原则每一行都要有稳定的、业务上唯一的key千万不要用数组下标当key。数组下标的 key 本质上就等于没有 key因为它在删除、插入后无法维持“同一身份”。2.3 按 id 去重而不是按下标一个真实事故有次我在封装组件时偷了个懒用index做了 key。当时觉得“反正是静态列表不会删也不会加”。结果产品经理的需求第二天就到了支持批量删除。批量删除之后表格行倒是减少了但第三行的状态图标全乱了——因为复用的是旧节点的 DOM而旧节点的状态类名还留在原地。排查过程其实不复杂我在删除逻辑里打了 console发现数据源内容是正确的那就基本锁定是渲染层复用出了问题。把 key 从index改成row.id之后问题立刻消失。那次之后我就给自己定死了规矩没有唯一 id 的表在拿到接口数据的第一时间就要主动添加一个_rowKey字段宁可多占点内存也不能让渲染层“瞎认亲”。3. 改了一行数据视图没反应更新链路上的三个“鬼门关”3.1 鬼门关一直接改 props等于给组件递了份复印件自定义 table 组件通常接收外部传入的数据比如props.tableData。很多新手写“更新”操作时直接在组件内部执行props.tableData[index].status done;这句话在 Vue 3 里通常不会直接生效因为直接修改 props 对象在开发模式下会有警告而且它会让数据流变得不可追踪。在 React 里就更不推荐了props 应该是只读的直接修改等于破坏了单向数据流。正确的更新方式应该是“事件上抛”组件内部通过emit告诉父组件“我要改这一行”然后由父组件把新的数据源传给子组件。也就是说数据源是唯一的更新动作应该发生在数据源的主人那里。这个模式虽然多写了几行代码但数据始终只有一个“权威来源”排查问题时你只需要看两处父组件的数据操作和子组件的渲染映射不用到处找是谁偷偷改了什么。3.2 鬼门关二把数组 push 成了堆setter 监听不到更新某个节点时有人喜欢这样写const newData tableData.value; newData[index].name 新名字;直接改数组某一项的话如果是 Vue 2数组的索引变更无法被Object.defineProperty拦截到视图自然不更新Vue 3 使用 Proxy 之后这个限制好了一些但如果嵌套层数过深有时也会遇到潜在问题。React 就更直接了——你改了 state 里数组的内存对象但没有调用setStateReact 根本不知道数据变了因为引用没变。这里有一个我觉得比较牢固的判断标准把“数据更新”想成一次“换新”而不是“抹改”。当你需要更新数组中的某一个 item 时最保险的方式是创建一个新的数组新数组里对应位置放一个新的对象。以 Vue 3 为例const index tableData.value.findIndex(row row.id targetId); if (index -1) { const newArray [...tableData.value]; newArray[index] { ...newArray[index], name: 新名字 }; tableData.value newArray; }这段代码做的事是先复制旧数组浅拷贝开销很小再替换对应位置为新对象最后整体赋值。区别在于数组的引用变了框架能明确感知“数据源整体变化了”从而触发渲染流程。虽然感觉上绕了一点但换来的是稳定性和可预测性。3.3 鬼门关三对象新增属性响应系统直接“失明”还有一个高频问题表格里每个对象一开始只有name和status你在更新时突然想加一个remark字段然后界面上怎么都不展示。原因在于 Vue 3 的响应式系统基于 Proxy虽然动态新增属性可以触发响应但如果你用的是Object.assign把整个对象替换掉、或者某些框架内部对对象做了冻结新增属性不一定被“观察”到。保险的做法是更新一行数据时把该行的对象也“换新”而且是完整地把所有要展示的字段都放进去。哪怕新加字段的值为空字符串也要显式带上。这样做有一个额外好处组件渲染的时候不会因为字段缺失报错类型也一目了然。newArray[index] { id: oldRow.id, name: oldRow.name, status: running, remark: 新增字段检查 };3.4 更新之后的渲染顺序diff 算法在 table 场景下的表现聊完三个鬼门关我们再往底层看一眼当你用“新数组替换旧数组”的方式更新数据后Vue/React 的渲染层会发生什么。以 Vue 3 为例组件会触发重新渲染然后对新旧虚拟节点做 patch。因为每个节点的 key 是稳定的iddiff 算法会快速匹配“哪些节点没变、哪些节点变了”。没变的直接跳过只有内容变化的那一行才会重新渲染并更新 DOM。这也解释了为什么key如此重要如果没有 keydiff 算法只能用“逐个比较”的方式把所有节点都过一遍遇到顺序变化还可能整块替换。有了稳定的 key它就能做到“按图索骥”——只处理真正有变化的那一行。自定义 table 在大数据量下是否卡顿很多时候拼的就是 key 的设计和更新时是否做到了“局部最小化”。4. 删除节点不只是 splice 这么简单4.1 删除的核心原则改数据不是动 DOM删除操作的核心逻辑很简单根据某个唯一标识把数据源数组中对应的那一项过滤掉。这里我推荐用filter而不是splice因为filter更符合“数据不可变”的操作理念function handleDelete(rowId) { tableData.value tableData.value.filter(row row.id ! rowId); }这一行代码完成了删除的全部核心工作数据源中移除该行渲染层感知到数组引用和内容变化自动把对应的tr移除。不要在这里去操作 DOM不要尝试手动抓document.querySelector去删节点——那是一条死路删完之后你还需要自己维护行号和 DOM 的对应关系相当于绕回了 jQuery 时代。4.2 踩过的坑删完数据之后复选框状态全乱了如果你做过带多选功能的表格应该能理解这种痛。表格第一列有一排复选框用户勾选了几行然后执行删除。很多人的第一版代码是这样的复选框选中的状态存在组件的本地selectedRows数组里用户勾选时把row对象推进去删除时从数据源中移除然后就……出问题了。问题出在两处。第一row对象是引用如果你在别处修改了对象内容数组里存的旧引用可能拿到的是脏数据第二删除之后selectedRows数组没有同步清理里面存了一堆“幽灵行”这些行在界面上已经不存在了但勾选计数、批量操作时会莫名其妙地把它们算进去。我的处理方式是不要存整行对象只存 id 数组。需要读取选中行的数据时再根据 id 去数据源里查找。删除后同步过滤掉已删除的 idconst selectedIds ref([]); function handleDelete(rowId) { tableData.value tableData.value.filter(row row.id ! rowId); selectedIds.value selectedIds.value.filter(id id ! rowId); }另外还有一个细节批量删除时最好在删除之前先拿到要删除的 id 集合然后一次性完成过滤和清除避免在循环里一边删除一边改索引。4.3 带过渡动画的删除让用户看到“发生了什么”从交互体验上来说直接“唰”地一下让一行消失总有种生硬感。但加删除动画其实是个“技术活”因为核心矛盾在于数据已经从数组里移除了可 DOM 还希望短暂地“存在一会儿”来完成淡出/收起动画。我的经验是用一个removingIds集合来记录“正在退场”的行。删除点击时不立即改数据源而是先把该行加入退场集合触发一个过渡动画动画结束后再真正从数据源移除并把 id 从退场集合里清理掉。伪代码逻辑如下const removingIds ref(new Set()); function removeWithAnimation(rowId) { removingIds.value.add(rowId); setTimeout(() { tableData.value tableData.value.filter(row row.id ! rowId); removingIds.value.delete(rowId); }, 300); }渲染时需要判断该行是否在退场集合中并把leaving类加上tr v-forrow in tableData :keyrow.id :class{ leaving: removingIds.has(row.id) } ... /tr配合 CSS 过渡或动画就能实现淡出高度收缩的效果。这段逻辑让删除有了一次平滑的“告别仪式”用户也能直观地感知数据确实被移除了。4.4 二次确认与撤销生产环境必须考虑的两个细节删除是破坏性操作生产环境的表格几乎都要求二次确认。这个需求本身不难但有个小地方容易忽略如果删除的是一行带子节点的数据或者删除会影响后续统计的节点一定要在确认弹窗里把“删了之后会造成什么影响”说清楚最好标注节点名称和数量。再说撤销。以我的经验撤销功能是删除操作里用户体验提升最明显、但成本也不算高的一个需求。实现思路并不复杂删除前把这一行对象深拷贝一份存到一个trashStack数组里然后提供“撤销”按钮点击时把对象插回原来的位置或者插入到末尾。const trashStack ref([]); function handleDelete(rowId) { const index tableData.value.findIndex(row row.id rowId); if (index -1) { trashStack.value.push({ index, row: JSON.parse(JSON.stringify(tableData.value[index])) }); tableData.value tableData.value.filter(row row.id ! rowId); } } function undo() { const last trashStack.value.pop(); if (last) { tableData.value.splice(last.index, 0, last.row); } }当然深拷贝用JSON.parse(JSON.stringify())只适用于纯数据对象如果里有函数、Date、RegExp 之类的类型建议用更健壮的深拷贝方案。核心思路是删除不是“彻底销毁”而是先“暂存”一个恢复入口。5. 实测复盘组件库里见过但你没深究的边界情况5.1 快速删除时 index 错位真凶往往是“异步闭包”有一种 bug 表现比较诡异用户快速连续点击多行的“删除”按钮结果删除的行和目标行总是对不上。比如点击第三行的删除结果第五行没了。这种问题大概率出在异步闭包里的 index 捕获上。常见写法是async function removeRow(row, index) { const res await confirmDelete(row.id); tableData.value.splice(index, 1); // index 是旧下标 }看起来没什么问题但假如用户在第一行删除的确认还没返回时第二行就发起了删除请求。等第一个确认返回时数据源可能已经因为第二个删除操作减少了行此时旧 index 已经失效再拿它去 splice删掉的自然不是预期的行。我在实际封装时推荐的姿势是永远不要拿“旧的 index”去删除数据而是始终靠唯一 id 定位行。上面filter的写法天然免疫这个问题因为它不依赖 index。如果某些场景必须用到 splice比如需要控制插入位置那也应该在异步操作返回后重新根据 id 查找最新的 index再执行删除。5.2 大数据量下的更新卡顿分片更新思路与时机表格数据量到了一定级别比如几千行以上频繁整表刷新会明显感觉卡顿。我在之前的一个调度任务表格里测过5000 行左右时全量替换 dataSource渲染时间能到 400ms 以上这种体验在交互里不可接受。优化的方向有几个局部更新只更新变更的那一行而不是每次倒腾整个数组。在 Vue 3 里可以通过ref的嵌套 明确指定行 id 实现。虚拟滚动只渲染可视区域内的行。这是数据量极大时的终极方案实现复杂度也高一些但收益巨大。分片更新如果确实需要一次更新很多行把数组拆成几个小批次每批次之间用requestAnimationFrame或setTimeout隔开避免一次渲染阻塞主线程太久。async function updateRowsByChunk(newRows, chunkSize 100) { for (let i 0; i newRows.length; i chunkSize) { const chunk newRows.slice(i, i chunkSize); // 将 chunk 更新进数据源 mergeRows(chunk); await nextTick(); // 等待当前批次渲染完成 } }不过分片更新的体验不是所有场景都适用——如果用户期待的是“一次性全部看到最新结果”分片反而会造成视觉上的撕裂感。我是倾向于在“定时轮询更新状态列”这种场景用分片普通用户主动触发的更新还是保持全量替换就行。5.3 跨项目迁移时的反思不同框架下的差异与一致性策略最后聊一段个人体会。我做过从 Vue 2 迁移到 Vue 3、以及从 jQuery 时代的表格迁移到 React 表格的项目最大的感受是“数据驱动”的理念是共通的差异只在具体写法上。Vue 2 的响应式有天然的缺陷——数组索引变动、新增属性都不触发更新所以在迁移时必须把所有“靠触发魔法”的代码改成“显式替换引用”的写法也就是前文反复提到的“新数组替换旧数组”。Vue 3 因为 Proxy 的增强很多旧写法能跑通了但为了保持组件行为的一致性我仍然建议采用不可变数据的风格。React 这边update 和 delete 都必须走setState这条显式路径反而逼着你把逻辑写得更清晰。还有一点值得说无论哪个框架表格组件的对外 API 设计比内部实现更影响后续维护。比如我自己的习惯是把updateRow(newRow)、deleteRow(id)、clearSelections()这些方法通过expose或者组件实例暴露出去让父组件调用而不是让父组件直接传一个巨大且频繁变化的数据源。这样组件的边界清晰各自负责什么一目了然。通过这些边界情况的复盘能明显感觉到写自定义 table 组件的难度不在单个功能点而在“数据、渲染、交互、性能”四者的协同一致。每一次更新和删除背后都牵动着数据的权威性、diff 的复用策略、用户的感知体验。把这些基础链路摸熟了再去封装自己的组件库心里会踏实得多。