1. 树形表格勾选的真实痛点与整体设计思路树形结构表格在中后台系统里出现的频率极高比如组织架构管理、菜单权限分配、商品多级分类、区域层级选择等场景。ElementUI 的el-table本身支持row-key加tree-props来渲染树形数据也支持typeselection的勾选列但这两者组合在一起时官方并没有提供勾父选子、半勾选、过滤半勾选节点这一整套联动逻辑。换句话说勾选列在树形模式下只是一个平铺的勾选父子节点之间没有任何级联关系这在实际业务里几乎没法直接用。我最早踩这个坑是在做一个权限分配模块的时候。需求很明确勾选一个父级菜单它下面所有子菜单自动全选取消父级子级全部取消如果只勾了部分子节点父级要显示成半勾选状态也就是那个横杠图标最后提交的时候还要能把所有处于半勾选状态的节点单独过滤出来做特殊处理。听起来是标准需求但真动手写才发现ElementUI 的 selection 在树形数据下根本不认这套逻辑toggleRowSelection对树形行的处理也有不少坑。所以这篇文章的核心就是把树形表格勾选联动这件事从头到尾拆开讲清楚。我会先讲整体设计思路和方案选型再拆解核心算法尤其是半勾选状态的判定和传播然后给出完整的实操代码和参数说明最后把我实际调试过程中遇到的典型问题和排查技巧整理成速查表。适合正在做中后台权限、分类、组织架构类功能的前端同学也适合想深入理解树形数据递归处理的朋友。哪怕你之前没怎么用过 ElementUI 的 selection跟着走一遍也能落地。先说结论性的设计思路避免大家走弯路。这套功能的核心其实就三件事第一维护一份选中集合用row-key作为唯一标识而不是依赖组件内部的 selection 数组第二用递归做状态传播勾选一个节点时向下递归全选/全不选向上递归计算父节点的全选或半选状态第三半勾选状态单独维护因为 ElementUI 的 selection 只有选中/未选中两态半选是我们自己算出来的必须额外存一份。把这三件事想清楚代码结构就清晰了。为什么不用el-tree而坚持用el-table这是很多人会问的。el-tree自带check-strictly和父子联动做勾选联动确实更省事。但业务上经常要求表格形式展示——要有列、要对齐、要能排序、要能自定义单元格el-tree在这些方面就力不从心了。所以用el-table的树形模式 自定义 selection 逻辑是兼顾表格形态和树形联动的最优解。代价就是联动逻辑得自己写这也是本文要解决的核心问题。2. 核心概念拆解全选、半选与选中集合的维护2.1 为什么不能直接用组件自带的 selectionElementUI 的el-table在typeselection模式下会维护一个内部选中的行数组通过selection-change事件抛出来。表面上看够用了但在树形场景下有几个致命问题。第一它不知道父子关系你勾了父节点子节点不会自动进 selection第二它没有半选概念父节点要么在数组里要么不在没法表达部分选中第三当你用代码toggleRowSelection去反向设置勾选状态时如果数据是异步加载或者动态展开的组件内部状态和你的预期经常对不上。我实测下来最稳的做法是自己维护一份selectedKeys选中集合和halfCheckedKeys半选集合组件自带的 selection 只用来做视觉呈现真正的状态以我们自己的集合为准。每次用户点击勾选框我们先更新自己的集合再通过toggleRowSelection把视觉状态同步过去。这样逻辑的真相源始终在我们手里不会被组件的内部行为带偏。这里有个关键点row-key必须是全局唯一的而且最好是稳定的字符串或数字。如果你的树形数据里 id 可能重复比如不同父节点下有相同子 id那整套逻辑都会崩。我一般会在数据预处理阶段就给每个节点生成一个唯一 key比如用路径拼接parentId-childId确保万无一失。2.2 全选、半选、未选三态的数学定义把状态定义清楚代码才好写。对任意一个节点 N设它的所有后代叶子节点集合为 L(N)已选中的叶子集合为 S那么全选L(N) 中所有节点都在 S 里即 L(N) ⊆ S未选L(N) 中没有任何节点在 S 里即 L(N) ∩ S ∅半选既不是全选也不是未选即部分后代被选中。注意这里我用的是后代叶子节点而不是直接子节点因为树可能有多层。用叶子节点做基准能避免中间层节点状态互相干扰。当然如果业务允许父节点本身也能被独立选中不联动子节点那定义要调整但绝大多数权限场景都是以叶子为准父节点状态由子节点推导。半选的判定逻辑就是该节点的后代中既有选中的又有未选中的。实现上递归拿到一个节点所有后代统计选中数量如果0 count total就是半选count total是全选count 0是未选。这个判定是整套逻辑的地基后面所有传播都建立在它之上。2.3 选中集合与半选集合的分离维护为什么要把半选单独存一个集合因为 ElementUI 的 selection 数组只能表达选中半选节点如果也塞进 selection会导致selection-change抛出的数据里混入不该提交的父节点。而业务上提交时通常只要叶子节点或者要单独处理半选节点。所以我的做法是selectedKeys只存真正被选中的节点通常是叶子也可能是被显式勾选的父节点halfCheckedKeys只存处于半选状态的父节点。两者互斥一个节点不可能既在 selectedKeys 又在 halfCheckedKeys。提交时如果只要叶子就过滤 selectedKeys 里没有子节点的如果要半选节点做特殊标记直接读 halfCheckedKeys。这样数据边界非常清晰不会出现提交了一堆父节点但后端只认叶子的尴尬。提示半选集合一定要在每次勾选操作后重新计算而不是增量更新。增量更新在多层树里极易出错全量重算虽然看起来笨但树节点数量通常不大几百到几千性能完全扛得住逻辑却简单可靠得多。3. 勾父选子的递归实现与状态传播3.1 向下传播勾选父节点时全选所有后代向下传播的逻辑相对简单当用户勾选一个节点时递归遍历它的所有后代把它们全部加入selectedKeys同时从halfCheckedKeys里移除因为全选了就不可能是半选。核心是一个深度优先遍历function selectAllDescendants(node, selectedSet, halfSet) { selectedSet.add(node.id); halfSet.delete(node.id); if (node.children node.children.length) { node.children.forEach(child { selectAllDescendants(child, selectedSet, halfSet); }); } }取消勾选时同理把后代全部从selectedKeys移除。这里有个细节父节点本身要不要进 selectedKeys我的建议是进。因为用户显式勾了父节点视觉上它就该是勾上的进集合没毛病。但提交时如果后端只要叶子记得过滤掉有 children 的节点。向下传播的触发时机是select事件用户点击勾选框和select-all事件点击表头全选。注意select-all在树形模式下行为比较特殊它只会勾选当前可见的行不会递归到折叠的子节点。所以如果你要全选所有得自己写一个遍历整棵树的函数而不是依赖select-all。3.2 向上传播根据子节点状态推导父节点状态向上传播是这套逻辑里最容易写错的部分。当某个子节点状态变化后它的父节点状态需要重新计算然后祖父节点也要重算一直递归到根。核心思路是对每个祖先节点统计它所有后代叶子的选中情况据此决定它是全选、半选还是未选。function updateAncestors(node, selectedSet, halfSet, nodeMap) { let parent nodeMap[node.parentId]; while (parent) { const stats countDescendants(parent, selectedSet); if (stats.selected 0) { selectedSet.delete(parent.id); halfSet.delete(parent.id); } else if (stats.selected stats.total) { selectedSet.add(parent.id); halfSet.delete(parent.id); } else { selectedSet.delete(parent.id); halfSet.add(parent.id); } parent nodeMap[parent.parentId]; } }countDescendants递归统计某节点后代总数和选中数。这里要注意统计的是叶子后代不是所有后代。因为中间层节点的选中状态是我们自己推导出来的不能作为统计依据否则会循环依赖。用叶子做基准逻辑才是自洽的。向上传播的终止条件是到达根节点parentId为空或不存在于 nodeMap。实际写的时候我建议先把树拍平成一个id - node的 map同时记录每个节点的parentId这样向上查找是 O(1)不用每次递归找父节点性能好很多。3.3 半勾选状态的视觉呈现状态算出来了还得让用户看得见。ElementUI 的 selection 列默认只有勾上和未勾两种图标半勾选需要我们自己控制。做法是在selection-change或者状态更新后遍历所有行对处于halfCheckedKeys的节点通过操作 DOM 或者自定义列模板来显示半选样式。比较稳妥的方案是用el-table-column的typeselection配合selectable属性但selectable只能控制能否勾选不能控制半选样式。所以真正显示半选图标通常有两种路子一是用 CSS 覆盖找到对应行的 checkbox 元素加上indeterminate类二是干脆放弃原生 selection 列自己用el-checkbox写一列通过:indeterminate属性原生支持半选。我实测下来自定义 checkbox 列是更可控的方案。原生 selection 列的 DOM 结构在不同版本间有差异用 CSS 硬覆盖容易在升级后失效。自己写一列用el-checkbox的indeterminate属性半选状态直接绑定数据稳定又清晰。代价是要自己处理表头全选和行点击但这点工作量换来的是完全可控值得。4. 过滤半勾选节点的完整实操4.1 过滤场景与数据准备过滤出半勾选节点这个需求通常出现在提交前的数据处理阶段。比如权限系统里半勾选的父节点意味着部分子权限被选中后端可能需要知道哪些父节点是部分选中的以便做特殊标记或者提示用户该模块权限不完整。所以过滤的目标就是从整棵树里把所有处于半选状态的节点单独拎出来。数据准备上你需要三样东西完整的树形数据用于遍历、selectedKeys集合、halfCheckedKeys集合。前两个是基础第三个是过滤的依据。如果你的半选集合是实时维护的直接拿来用即可如果担心状态不同步可以在过滤前重新全量计算一遍半选集合确保准确。我一般会写一个recomputeHalfChecked函数遍历整棵树对每个有子节点的节点调用countDescendants根据结果重建halfCheckedKeys。这个函数在提交前调用一次能兜住所有可能的中间状态错误。虽然多算一遍但提交是低频操作性能无所谓正确性优先。4.2 递归过滤的实现与边界处理过滤本身就是一个树的深度优先遍历把halfCheckedKeys里包含的节点收集起来function filterHalfChecked(tree, halfSet, result []) { tree.forEach(node { if (halfSet.has(node.id)) { result.push(node); } if (node.children node.children.length) { filterHalfChecked(node.children, halfSet, result); } }); return result; }看起来简单但边界情况不少。第一根节点也可能是半选遍历要从根开始不能漏。第二过滤结果要不要包含子节点通常只要半选节点本身不要它的后代因为后代状态是它半选的原因不是结果。第三如果某个半选节点的父节点也是半选两个都要收集因为它们代表不同层级的部分选中业务上可能都需要。还有一个容易忽略的点过滤出来的节点顺序。递归遍历是深度优先出来的顺序是父在前、子在后的树序。如果业务要求按层级或者按 id 排序记得在结果上再排一次。我一般会保留树序因为这样最直观用户看到的结果和界面层级一致。4.3 提交数据的组装策略过滤出半选节点后最终提交的数据通常是这样组装的selectedKeys里的叶子节点真正被授权的halfCheckedKeys里的半选节点部分授权的标记。有些系统还会额外带上全选节点方便后端快速判断某个模块是否完整授权。组装时要注意去重和互斥。前面说过 selectedKeys 和 halfCheckedKeys 是互斥的但如果你在过滤前重新计算了半选集合理论上不会重叠。保险起见组装时还是做一次交集检查把同时出现在两个集合里的节点从半选集合里剔除避免数据矛盾。提示提交前建议打印一份选中叶子数 / 半选节点数 / 总节点数的统计日志。这个日志在联调阶段能帮你快速定位为什么提交的数据和界面显示不一致这类问题非常实用。5. 常见问题与排查技巧实录5.1 勾选状态与界面不同步的排查这是最高频的问题代码里selectedKeys明明更新了但界面上的勾选框没变。原因通常是只更新了数据集合没有调用toggleRowSelection同步视觉状态。ElementUI 的 selection 是组件内部状态你改自己的集合它不知道必须显式调用 API 去同步。排查步骤第一确认row-key配置正确且唯一第二确认在更新集合后遍历了所有受影响的行并调用了toggleRowSelection(row, isSelected)第三如果树是动态展开的注意折叠状态下子节点可能还没渲染toggleRowSelection会失效需要等展开后再同步或者干脆在展开事件里重新同步一次状态。我踩过最深的坑是异步加载子节点后父节点的半选状态没重算。因为子节点是后加载的加载前父节点可能被判定为全选加载后才发现应该半选。解决办法是在子节点加载完成的回调里重新触发一次向上传播把祖先状态刷新一遍。5.2 半选状态丢失或误判的处理半选状态误判十有八九是统计基准搞错了。如果你统计的是所有后代而不是叶子后代中间层节点的状态会干扰计算导致父节点明明该半选却被判成全选。记住半选判定永远以叶子为准。另一个常见原因是集合没有及时清理。比如取消勾选时只从 selectedKeys 删了忘了从 halfCheckedKeys 删导致一个节点既不在选中集合又被标记为半选状态自相矛盾。每次状态变更后建议对相关节点做一次三态归一确保它只属于全选、半选、未选三者之一。还有一种情况是数据里有重复 id。树形数据如果 id 不唯一map 会互相覆盖状态全乱。排查时先打印一遍所有 id看看有没有重复。有的话在数据预处理阶段就生成唯一 key别等到出问题再回头改。5.3 性能问题与大数据量优化树节点上千之后每次勾选都全量重算半选集合可能会有卡顿。优化思路有几个第一只重算受影响的祖先链而不是整棵树。勾选一个节点只有它的祖先状态可能变其他分支不受影响。第二用 map 缓存节点引用避免每次递归都重新查找。第三防抖处理如果用户快速连续勾选可以合并成一次计算。不过说实话除非你的树有上万节点否则全量重算完全够用。我做过一个三千多节点的权限树全量重算一次大概几毫秒用户根本感知不到。所以我的建议是先保证逻辑正确性能真出问题了再优化别一上来就搞复杂的增量更新容易写出 bug。问题现象可能原因排查方向勾选后界面不变未同步组件 selection检查 toggleRowSelection 调用父节点该半选却全选统计基准用了所有后代改为只统计叶子后代状态自相矛盾集合未清理或 id 重复检查集合互斥性与 id 唯一性异步加载后状态错未重算祖先状态加载回调里触发向上传播大数据量卡顿全量重算过于频繁增量更新或防抖5.4 折叠展开与状态保持的坑树形表格折叠再展开后勾选状态丢失这个问题困扰过很多人。根本原因是折叠时子节点被销毁展开时重新渲染组件内部的 selection 状态没了。但因为我们的真相源是selectedKeys集合只要在展开时根据集合重新toggleRowSelection一遍状态就能恢复。具体做法是监听expand-change事件在展开某行后遍历它的子节点根据selectedKeys和halfCheckedKeys重新设置勾选和半选状态。这个同步逻辑最好封装成一个函数展开、加载、初始化都调它保证任何时机状态都一致。还有一个细节el-table的树形展开默认是懒加载还是全量渲染取决于你的数据结构。如果是全量渲染children 直接嵌在数据里折叠只是隐藏 DOM状态其实还在问题不大。如果是懒加载点击才请求子节点那每次展开都是新数据必须手动同步状态。两种模式的处理方式不同要先确认自己用的是哪种。6. 完整实现的关键代码与参数说明6.1 数据结构与 row-key 设计先把数据结构定下来。我一般用这样的结构{ id: unique-id, parentId: parent-unique-id | null, label: 节点名称, children: [ /* 子节点数组 */ ] }id全局唯一parentId指向父节点根节点为 nullchildren是子节点数组。同时我会在初始化时构建两个辅助结构nodeMapid 到节点的映射和parentMapid 到 parentId 的映射方便 O(1) 查找。row-key直接绑定id。如果你的数据里 id 可能重复就在预处理阶段生成复合 key比如id - parentId确保唯一。这一步千万别省后面所有逻辑都依赖它。6.2 勾选事件处理与状态同步核心的勾选处理函数大概长这样handleSelect(selection, row) { const isSelected this.selectedKeys.has(row.id); if (isSelected) { this.selectedKeys.delete(row.id); this.unselectAllDescendants(row); } else { this.selectedKeys.add(row.id); this.selectAllDescendants(row); } this.updateAncestors(row); this.syncTableSelection(); }syncTableSelection负责把集合状态同步到组件视觉上遍历所有已渲染的行对每行调用toggleRowSelection(row, this.selectedKeys.has(row.id))。注意半选状态不走这个方法半选是自定义列绑定的直接读halfCheckedKeys即可。6.3 半选列的自定义渲染放弃原生 selection 列自己写一列el-table-column width50 template slot-scope{ row } el-checkbox :valueselectedKeys.has(row.id) :indeterminatehalfCheckedKeys.has(row.id) changehandleCheckboxChange(row) / /template /el-table-columnel-checkbox的indeterminate属性原生支持半选样式绑定halfCheckedKeys即可。value绑定选中状态change事件里调用我们的勾选处理逻辑。这样半选、全选、未选三态都能正确显示而且完全可控不受组件版本影响。表头的全选 checkbox 也类似处理用一个计算属性判断当前是否全选或半选绑定到表头的 checkbox 上。点击表头时遍历整棵树做全选或全不选。6.4 过滤半选节点的最终封装最后把过滤逻辑封装成一个方法供提交时调用getHalfCheckedNodes() { this.recomputeHalfChecked(); const result []; const traverse (nodes) { nodes.forEach(node { if (this.halfCheckedKeys.has(node.id)) { result.push({ id: node.id, label: node.label }); } if (node.children node.children.length) { traverse(node.children); } }); }; traverse(this.treeData); return result; }返回的结果只包含 id 和 label 这类必要字段避免把整个节点对象可能很大传给后端。如果业务需要更多字段按需补充即可。这个方法在提交前调用配合前面说的统计日志能确保提交数据准确无误。整套逻辑写下来代码量其实不大核心就是集合维护 递归传播 状态同步三块。真正花时间的是调试各种边界情况比如异步加载、折叠展开、快速连续点击。把这些坑都趟过一遍之后你会发现这套模式可以复用到任何树形勾选场景换个数据结构就能用非常通用。
1. 树形表格勾选的真实痛点与整体设计思路树形结构表格在中后台系统里出现的频率极高比如组织架构管理、菜单权限分配、商品多级分类、区域层级选择等场景。ElementUI 的el-table本身支持row-key加tree-props来渲染树形数据也支持typeselection的勾选列但这两者组合在一起时官方并没有提供勾父选子、半勾选、过滤半勾选节点这一整套联动逻辑。换句话说勾选列在树形模式下只是一个平铺的勾选父子节点之间没有任何级联关系这在实际业务里几乎没法直接用。我最早踩这个坑是在做一个权限分配模块的时候。需求很明确勾选一个父级菜单它下面所有子菜单自动全选取消父级子级全部取消如果只勾了部分子节点父级要显示成半勾选状态也就是那个横杠图标最后提交的时候还要能把所有处于半勾选状态的节点单独过滤出来做特殊处理。听起来是标准需求但真动手写才发现ElementUI 的 selection 在树形数据下根本不认这套逻辑toggleRowSelection对树形行的处理也有不少坑。所以这篇文章的核心就是把树形表格勾选联动这件事从头到尾拆开讲清楚。我会先讲整体设计思路和方案选型再拆解核心算法尤其是半勾选状态的判定和传播然后给出完整的实操代码和参数说明最后把我实际调试过程中遇到的典型问题和排查技巧整理成速查表。适合正在做中后台权限、分类、组织架构类功能的前端同学也适合想深入理解树形数据递归处理的朋友。哪怕你之前没怎么用过 ElementUI 的 selection跟着走一遍也能落地。先说结论性的设计思路避免大家走弯路。这套功能的核心其实就三件事第一维护一份选中集合用row-key作为唯一标识而不是依赖组件内部的 selection 数组第二用递归做状态传播勾选一个节点时向下递归全选/全不选向上递归计算父节点的全选或半选状态第三半勾选状态单独维护因为 ElementUI 的 selection 只有选中/未选中两态半选是我们自己算出来的必须额外存一份。把这三件事想清楚代码结构就清晰了。为什么不用el-tree而坚持用el-table这是很多人会问的。el-tree自带check-strictly和父子联动做勾选联动确实更省事。但业务上经常要求表格形式展示——要有列、要对齐、要能排序、要能自定义单元格el-tree在这些方面就力不从心了。所以用el-table的树形模式 自定义 selection 逻辑是兼顾表格形态和树形联动的最优解。代价就是联动逻辑得自己写这也是本文要解决的核心问题。2. 核心概念拆解全选、半选与选中集合的维护2.1 为什么不能直接用组件自带的 selectionElementUI 的el-table在typeselection模式下会维护一个内部选中的行数组通过selection-change事件抛出来。表面上看够用了但在树形场景下有几个致命问题。第一它不知道父子关系你勾了父节点子节点不会自动进 selection第二它没有半选概念父节点要么在数组里要么不在没法表达部分选中第三当你用代码toggleRowSelection去反向设置勾选状态时如果数据是异步加载或者动态展开的组件内部状态和你的预期经常对不上。我实测下来最稳的做法是自己维护一份selectedKeys选中集合和halfCheckedKeys半选集合组件自带的 selection 只用来做视觉呈现真正的状态以我们自己的集合为准。每次用户点击勾选框我们先更新自己的集合再通过toggleRowSelection把视觉状态同步过去。这样逻辑的真相源始终在我们手里不会被组件的内部行为带偏。这里有个关键点row-key必须是全局唯一的而且最好是稳定的字符串或数字。如果你的树形数据里 id 可能重复比如不同父节点下有相同子 id那整套逻辑都会崩。我一般会在数据预处理阶段就给每个节点生成一个唯一 key比如用路径拼接parentId-childId确保万无一失。2.2 全选、半选、未选三态的数学定义把状态定义清楚代码才好写。对任意一个节点 N设它的所有后代叶子节点集合为 L(N)已选中的叶子集合为 S那么全选L(N) 中所有节点都在 S 里即 L(N) ⊆ S未选L(N) 中没有任何节点在 S 里即 L(N) ∩ S ∅半选既不是全选也不是未选即部分后代被选中。注意这里我用的是后代叶子节点而不是直接子节点因为树可能有多层。用叶子节点做基准能避免中间层节点状态互相干扰。当然如果业务允许父节点本身也能被独立选中不联动子节点那定义要调整但绝大多数权限场景都是以叶子为准父节点状态由子节点推导。半选的判定逻辑就是该节点的后代中既有选中的又有未选中的。实现上递归拿到一个节点所有后代统计选中数量如果0 count total就是半选count total是全选count 0是未选。这个判定是整套逻辑的地基后面所有传播都建立在它之上。2.3 选中集合与半选集合的分离维护为什么要把半选单独存一个集合因为 ElementUI 的 selection 数组只能表达选中半选节点如果也塞进 selection会导致selection-change抛出的数据里混入不该提交的父节点。而业务上提交时通常只要叶子节点或者要单独处理半选节点。所以我的做法是selectedKeys只存真正被选中的节点通常是叶子也可能是被显式勾选的父节点halfCheckedKeys只存处于半选状态的父节点。两者互斥一个节点不可能既在 selectedKeys 又在 halfCheckedKeys。提交时如果只要叶子就过滤 selectedKeys 里没有子节点的如果要半选节点做特殊标记直接读 halfCheckedKeys。这样数据边界非常清晰不会出现提交了一堆父节点但后端只认叶子的尴尬。提示半选集合一定要在每次勾选操作后重新计算而不是增量更新。增量更新在多层树里极易出错全量重算虽然看起来笨但树节点数量通常不大几百到几千性能完全扛得住逻辑却简单可靠得多。3. 勾父选子的递归实现与状态传播3.1 向下传播勾选父节点时全选所有后代向下传播的逻辑相对简单当用户勾选一个节点时递归遍历它的所有后代把它们全部加入selectedKeys同时从halfCheckedKeys里移除因为全选了就不可能是半选。核心是一个深度优先遍历function selectAllDescendants(node, selectedSet, halfSet) { selectedSet.add(node.id); halfSet.delete(node.id); if (node.children node.children.length) { node.children.forEach(child { selectAllDescendants(child, selectedSet, halfSet); }); } }取消勾选时同理把后代全部从selectedKeys移除。这里有个细节父节点本身要不要进 selectedKeys我的建议是进。因为用户显式勾了父节点视觉上它就该是勾上的进集合没毛病。但提交时如果后端只要叶子记得过滤掉有 children 的节点。向下传播的触发时机是select事件用户点击勾选框和select-all事件点击表头全选。注意select-all在树形模式下行为比较特殊它只会勾选当前可见的行不会递归到折叠的子节点。所以如果你要全选所有得自己写一个遍历整棵树的函数而不是依赖select-all。3.2 向上传播根据子节点状态推导父节点状态向上传播是这套逻辑里最容易写错的部分。当某个子节点状态变化后它的父节点状态需要重新计算然后祖父节点也要重算一直递归到根。核心思路是对每个祖先节点统计它所有后代叶子的选中情况据此决定它是全选、半选还是未选。function updateAncestors(node, selectedSet, halfSet, nodeMap) { let parent nodeMap[node.parentId]; while (parent) { const stats countDescendants(parent, selectedSet); if (stats.selected 0) { selectedSet.delete(parent.id); halfSet.delete(parent.id); } else if (stats.selected stats.total) { selectedSet.add(parent.id); halfSet.delete(parent.id); } else { selectedSet.delete(parent.id); halfSet.add(parent.id); } parent nodeMap[parent.parentId]; } }countDescendants递归统计某节点后代总数和选中数。这里要注意统计的是叶子后代不是所有后代。因为中间层节点的选中状态是我们自己推导出来的不能作为统计依据否则会循环依赖。用叶子做基准逻辑才是自洽的。向上传播的终止条件是到达根节点parentId为空或不存在于 nodeMap。实际写的时候我建议先把树拍平成一个id - node的 map同时记录每个节点的parentId这样向上查找是 O(1)不用每次递归找父节点性能好很多。3.3 半勾选状态的视觉呈现状态算出来了还得让用户看得见。ElementUI 的 selection 列默认只有勾上和未勾两种图标半勾选需要我们自己控制。做法是在selection-change或者状态更新后遍历所有行对处于halfCheckedKeys的节点通过操作 DOM 或者自定义列模板来显示半选样式。比较稳妥的方案是用el-table-column的typeselection配合selectable属性但selectable只能控制能否勾选不能控制半选样式。所以真正显示半选图标通常有两种路子一是用 CSS 覆盖找到对应行的 checkbox 元素加上indeterminate类二是干脆放弃原生 selection 列自己用el-checkbox写一列通过:indeterminate属性原生支持半选。我实测下来自定义 checkbox 列是更可控的方案。原生 selection 列的 DOM 结构在不同版本间有差异用 CSS 硬覆盖容易在升级后失效。自己写一列用el-checkbox的indeterminate属性半选状态直接绑定数据稳定又清晰。代价是要自己处理表头全选和行点击但这点工作量换来的是完全可控值得。4. 过滤半勾选节点的完整实操4.1 过滤场景与数据准备过滤出半勾选节点这个需求通常出现在提交前的数据处理阶段。比如权限系统里半勾选的父节点意味着部分子权限被选中后端可能需要知道哪些父节点是部分选中的以便做特殊标记或者提示用户该模块权限不完整。所以过滤的目标就是从整棵树里把所有处于半选状态的节点单独拎出来。数据准备上你需要三样东西完整的树形数据用于遍历、selectedKeys集合、halfCheckedKeys集合。前两个是基础第三个是过滤的依据。如果你的半选集合是实时维护的直接拿来用即可如果担心状态不同步可以在过滤前重新全量计算一遍半选集合确保准确。我一般会写一个recomputeHalfChecked函数遍历整棵树对每个有子节点的节点调用countDescendants根据结果重建halfCheckedKeys。这个函数在提交前调用一次能兜住所有可能的中间状态错误。虽然多算一遍但提交是低频操作性能无所谓正确性优先。4.2 递归过滤的实现与边界处理过滤本身就是一个树的深度优先遍历把halfCheckedKeys里包含的节点收集起来function filterHalfChecked(tree, halfSet, result []) { tree.forEach(node { if (halfSet.has(node.id)) { result.push(node); } if (node.children node.children.length) { filterHalfChecked(node.children, halfSet, result); } }); return result; }看起来简单但边界情况不少。第一根节点也可能是半选遍历要从根开始不能漏。第二过滤结果要不要包含子节点通常只要半选节点本身不要它的后代因为后代状态是它半选的原因不是结果。第三如果某个半选节点的父节点也是半选两个都要收集因为它们代表不同层级的部分选中业务上可能都需要。还有一个容易忽略的点过滤出来的节点顺序。递归遍历是深度优先出来的顺序是父在前、子在后的树序。如果业务要求按层级或者按 id 排序记得在结果上再排一次。我一般会保留树序因为这样最直观用户看到的结果和界面层级一致。4.3 提交数据的组装策略过滤出半选节点后最终提交的数据通常是这样组装的selectedKeys里的叶子节点真正被授权的halfCheckedKeys里的半选节点部分授权的标记。有些系统还会额外带上全选节点方便后端快速判断某个模块是否完整授权。组装时要注意去重和互斥。前面说过 selectedKeys 和 halfCheckedKeys 是互斥的但如果你在过滤前重新计算了半选集合理论上不会重叠。保险起见组装时还是做一次交集检查把同时出现在两个集合里的节点从半选集合里剔除避免数据矛盾。提示提交前建议打印一份选中叶子数 / 半选节点数 / 总节点数的统计日志。这个日志在联调阶段能帮你快速定位为什么提交的数据和界面显示不一致这类问题非常实用。5. 常见问题与排查技巧实录5.1 勾选状态与界面不同步的排查这是最高频的问题代码里selectedKeys明明更新了但界面上的勾选框没变。原因通常是只更新了数据集合没有调用toggleRowSelection同步视觉状态。ElementUI 的 selection 是组件内部状态你改自己的集合它不知道必须显式调用 API 去同步。排查步骤第一确认row-key配置正确且唯一第二确认在更新集合后遍历了所有受影响的行并调用了toggleRowSelection(row, isSelected)第三如果树是动态展开的注意折叠状态下子节点可能还没渲染toggleRowSelection会失效需要等展开后再同步或者干脆在展开事件里重新同步一次状态。我踩过最深的坑是异步加载子节点后父节点的半选状态没重算。因为子节点是后加载的加载前父节点可能被判定为全选加载后才发现应该半选。解决办法是在子节点加载完成的回调里重新触发一次向上传播把祖先状态刷新一遍。5.2 半选状态丢失或误判的处理半选状态误判十有八九是统计基准搞错了。如果你统计的是所有后代而不是叶子后代中间层节点的状态会干扰计算导致父节点明明该半选却被判成全选。记住半选判定永远以叶子为准。另一个常见原因是集合没有及时清理。比如取消勾选时只从 selectedKeys 删了忘了从 halfCheckedKeys 删导致一个节点既不在选中集合又被标记为半选状态自相矛盾。每次状态变更后建议对相关节点做一次三态归一确保它只属于全选、半选、未选三者之一。还有一种情况是数据里有重复 id。树形数据如果 id 不唯一map 会互相覆盖状态全乱。排查时先打印一遍所有 id看看有没有重复。有的话在数据预处理阶段就生成唯一 key别等到出问题再回头改。5.3 性能问题与大数据量优化树节点上千之后每次勾选都全量重算半选集合可能会有卡顿。优化思路有几个第一只重算受影响的祖先链而不是整棵树。勾选一个节点只有它的祖先状态可能变其他分支不受影响。第二用 map 缓存节点引用避免每次递归都重新查找。第三防抖处理如果用户快速连续勾选可以合并成一次计算。不过说实话除非你的树有上万节点否则全量重算完全够用。我做过一个三千多节点的权限树全量重算一次大概几毫秒用户根本感知不到。所以我的建议是先保证逻辑正确性能真出问题了再优化别一上来就搞复杂的增量更新容易写出 bug。问题现象可能原因排查方向勾选后界面不变未同步组件 selection检查 toggleRowSelection 调用父节点该半选却全选统计基准用了所有后代改为只统计叶子后代状态自相矛盾集合未清理或 id 重复检查集合互斥性与 id 唯一性异步加载后状态错未重算祖先状态加载回调里触发向上传播大数据量卡顿全量重算过于频繁增量更新或防抖5.4 折叠展开与状态保持的坑树形表格折叠再展开后勾选状态丢失这个问题困扰过很多人。根本原因是折叠时子节点被销毁展开时重新渲染组件内部的 selection 状态没了。但因为我们的真相源是selectedKeys集合只要在展开时根据集合重新toggleRowSelection一遍状态就能恢复。具体做法是监听expand-change事件在展开某行后遍历它的子节点根据selectedKeys和halfCheckedKeys重新设置勾选和半选状态。这个同步逻辑最好封装成一个函数展开、加载、初始化都调它保证任何时机状态都一致。还有一个细节el-table的树形展开默认是懒加载还是全量渲染取决于你的数据结构。如果是全量渲染children 直接嵌在数据里折叠只是隐藏 DOM状态其实还在问题不大。如果是懒加载点击才请求子节点那每次展开都是新数据必须手动同步状态。两种模式的处理方式不同要先确认自己用的是哪种。6. 完整实现的关键代码与参数说明6.1 数据结构与 row-key 设计先把数据结构定下来。我一般用这样的结构{ id: unique-id, parentId: parent-unique-id | null, label: 节点名称, children: [ /* 子节点数组 */ ] }id全局唯一parentId指向父节点根节点为 nullchildren是子节点数组。同时我会在初始化时构建两个辅助结构nodeMapid 到节点的映射和parentMapid 到 parentId 的映射方便 O(1) 查找。row-key直接绑定id。如果你的数据里 id 可能重复就在预处理阶段生成复合 key比如id - parentId确保唯一。这一步千万别省后面所有逻辑都依赖它。6.2 勾选事件处理与状态同步核心的勾选处理函数大概长这样handleSelect(selection, row) { const isSelected this.selectedKeys.has(row.id); if (isSelected) { this.selectedKeys.delete(row.id); this.unselectAllDescendants(row); } else { this.selectedKeys.add(row.id); this.selectAllDescendants(row); } this.updateAncestors(row); this.syncTableSelection(); }syncTableSelection负责把集合状态同步到组件视觉上遍历所有已渲染的行对每行调用toggleRowSelection(row, this.selectedKeys.has(row.id))。注意半选状态不走这个方法半选是自定义列绑定的直接读halfCheckedKeys即可。6.3 半选列的自定义渲染放弃原生 selection 列自己写一列el-table-column width50 template slot-scope{ row } el-checkbox :valueselectedKeys.has(row.id) :indeterminatehalfCheckedKeys.has(row.id) changehandleCheckboxChange(row) / /template /el-table-columnel-checkbox的indeterminate属性原生支持半选样式绑定halfCheckedKeys即可。value绑定选中状态change事件里调用我们的勾选处理逻辑。这样半选、全选、未选三态都能正确显示而且完全可控不受组件版本影响。表头的全选 checkbox 也类似处理用一个计算属性判断当前是否全选或半选绑定到表头的 checkbox 上。点击表头时遍历整棵树做全选或全不选。6.4 过滤半选节点的最终封装最后把过滤逻辑封装成一个方法供提交时调用getHalfCheckedNodes() { this.recomputeHalfChecked(); const result []; const traverse (nodes) { nodes.forEach(node { if (this.halfCheckedKeys.has(node.id)) { result.push({ id: node.id, label: node.label }); } if (node.children node.children.length) { traverse(node.children); } }); }; traverse(this.treeData); return result; }返回的结果只包含 id 和 label 这类必要字段避免把整个节点对象可能很大传给后端。如果业务需要更多字段按需补充即可。这个方法在提交前调用配合前面说的统计日志能确保提交数据准确无误。整套逻辑写下来代码量其实不大核心就是集合维护 递归传播 状态同步三块。真正花时间的是调试各种边界情况比如异步加载、折叠展开、快速连续点击。把这些坑都趟过一遍之后你会发现这套模式可以复用到任何树形勾选场景换个数据结构就能用非常通用。
