企业官网建设流程全解析

1. 树形表格勾选的真实痛点与整体设计思路

树形结构表格在中后台系统里出现的频率极高，比如组织架构管理、菜单权限分配、商品多级分类、区域层级选择等场景。ElementUI 的el-table本身支持row-key加tree-props来渲染树形数据，也支持type="selection"的勾选列，但这两者组合在一起时，官方并没有提供"勾父选子、半勾选、过滤半勾选节点"这一整套联动逻辑。换句话说，勾选列在树形模式下只是一个"平铺"的勾选，父子节点之间没有任何级联关系，这在实际业务里几乎没法直接用。

我最早踩这个坑是在做一个权限分配模块的时候。需求很明确：勾选一个父级菜单，它下面所有子菜单自动全选；取消父级，子级全部取消；如果只勾了部分子节点，父级要显示成"半勾选"状态（也就是那个横杠图标）；最后提交的时候，还要能把所有处于半勾选状态的节点单独过滤出来做特殊处理。听起来是标准需求，但真动手写才发现，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 为什么不能直接用组件自带的 selection

ElementUI 的el-table在type="selection"模式下，会维护一个内部选中的行数组，通过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的type="selection"配合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。

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指向父节点（根节点为 null），children是子节点数组。同时我会在初始化时构建两个辅助结构：nodeMap（id 到节点的映射）和parentMap（id 到 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 width="50"> <template slot-scope="{ row }"> <el-checkbox :value="selectedKeys.has(row.id)" :indeterminate="halfCheckedKeys.has(row.id)" @change="handleCheckboxChange(row)" /> </template> </el-table-column>

el-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 这类必要字段，避免把整个节点对象（可能很大）传给后端。如果业务需要更多字段，按需补充即可。这个方法在提交前调用，配合前面说的统计日志，能确保提交数据准确无误。

整套逻辑写下来，代码量其实不大，核心就是"集合维护 + 递归传播 + 状态同步"三块。真正花时间的是调试各种边界情况，比如异步加载、折叠展开、快速连续点击。把这些坑都趟过一遍之后，你会发现这套模式可以复用到任何树形勾选场景，换个数据结构就能用，非常通用。