企业官网建设流程全解析

1.3 真实配置对比

这样一列，方案就清晰了：跨页全选不是“让表格记住跨页”，而是把整张表格的选中结果从“临时状态”提升为“业务数据”，永远挂在业务层。这也是整篇的核心思路，后面所有实现都是围绕这一句话展开的。

2. 两条技术路线：reserve-selection和手动Map管理怎么选

讲完原理，肯定有人会问：Element官方不是给了reserve-selection属性吗？为什么还要自己存Map？这个问题很自然，因为官方方案确实是很多人第一眼看到的解。但我必须说清楚：reserve-selection能用，但它在生产环境有一堆隐藏前提，很多团队是踩完坑才回头换手动管理的。我下面把两条路线都摆出来，你们自己权衡。

2.1 reserve-selection：官方保留选中的快速方案，但有几个隐藏前提

先给快速方案的正解代码。用reserve-selection实现跨页保留选中，代码量非常少：

<template> <el-table ref="tableRef" :data="pageData" row-key="id" @selection-change="handleSelectionChange" > <el-table-column type="selection" reserve-selection width="55" /> <el-table-column prop="name" label="姓名" min-width="120" /> <el-table-column prop="dept" label="部门" min-width="120" /> </el-table> </template>

export default { data() { return { pageData: [], selectedRows: [], }; }, methods: { handleSelectionChange(selection) { // reserve-selection 生效时，selection 会包含其他页已选中的行 // 但这里有一个关键点：它保存的是行对象的引用，不是快照 this.selectedRows = selection; }, }, };

用过的人都觉得爽，翻页切回来，上一页勾选的checkbox还在，不需要写一行恢复逻辑。但我后面在实际项目里逐步发现了它的坑，而且每一个坑都挺隐蔽：

第一，必须同时设置row-key，且row-key对应的字段必须在数据刷新后保持不变。如果你的列表id是后端生成的，筛选和排序后返回的新数据行id不变，那没问题；但如果你用遍历索引当row-key，或者数据经过前端处理后id变了，reserve-selection会把旧key对应的选中残留到一个根本不存在的行上，表现就是“数据刷新后，之前勾选的行没在列表里，但提交时还在selectedRows里”。这种鬼问题极难排查，因为界面看起来是正常的。

第二，异步数据初始化的时序会坑人。表格先渲染空data，再请求接口返回pageData，这个过程中reserve-selection的regist逻辑有时会滞后。我遇到过一种场景：搜索条件变更后重新查数据，第一帧pageData是空数组，选中状态被清空一次，等新数据回来时reserve-selection没有恢复之前的key，跨页选中全丢了。这个bug不是必现，但一旦出现在线上，用户骂的就是你。

第三，v-if重建表格、动态渲染el-table-column（比如根据权限控制某些列显隐）、或者多次clearSelection()调用，都会让reserve-selection直接失效或误清全量。很多后台系统喜欢用v-if控制表格在“数据模式”和“空状态模式”之间切换，结果切换回来选中全没了。你要是用reserve-selection，就必须保证表格组件从创建到销毁的生命周期内，data和列配置都不能有大的结构变化。

第四，也是我最不推荐的一点：selectedRows里存的是行对象引用，不是快照。如果后续你对行数据做了修改（比如编辑了某个字段），或者接口返回时某些字段没带全，提交时从selectedRows里取到的可能是旧引用或残缺字段。如果你需要“勾选后立刻把这一行某字段锁定，允许后续修改但提交用锁定值”，这种需求reserve-selection就满足不了。

所以我的结论是：reserve-selection适合“列表数据稳定、不动态改列、不重建表格、只做勾选提交”的轻量场景。它写起来快，但你也必须承担它的隐性约束。一旦你的系统里存在上面任何一条，建议直接跳到手动管理方案。

2.2 为什么生产环境我最终选择了手动Map管理

我在实际负责的中后台项目里，表格往往同时具备这些特征：分页 + 搜索筛选 + 后端排序 + 权限控制列显隐 + 数据半路修改字段 + 切换账号后重新加载数据。把这些特征叠在一起，reserve-selection那套“组件替我记，数据跟着行引用走”的机制就变得不可靠。这就是我后来放弃它，改成手动维护一个selectedMap的根本原因。

手动管理方案的核心就一句话：选中状态从“表格内部状态”变成“业务组件的响应式数据”，表格只负责展示当前页哪些行被勾选，真正的选中集合由你全权掌控。

这样做有几个实实在在的好处：

• 数据和UI解耦：selectedMap存的是行数据快照，哪怕后续列表重新查询、排序、甚至当前页不存在这条数据，只要key还在Map里，提交时就能取到完整的行信息。
• 各种边界情况可编程：切换筛选条件、清空选中、批量操作、限制最大选择数，全部可以在业务层写逻辑，不用猜组件内部行为。
• 性能可预估：选中集合的操作都是Map的set/delete/has，时间复杂度O(1)，几千上万条选中数据也不慌。

当然代价也明显：代码量变多了，翻页后要自己调toggleRowSelection回显，还要加标志位防止死循环。但对比线上数据错乱的投诉，我宁愿多写这几十行代码。

2.3 核心思路：把选中状态提升到业务层

在写代码之前，我要先把数据流画出来，这能帮你理解整个方案为什么设计成这样：

正常勾选链路：用户点复选框 ->@select或@select-all事件触发 -> 根据勾选或取消，向selectedMap写入或删除key -> 表格继续走它的正常渲染。

翻页恢复链路：页码变化 -> 请求新一页数据 ->pageData更新 ->watch或方法调用进入restoreSelection-> 遍历当前页每行，判断key在不在selectedMap-> 在则toggleRowSelection(row, true)回显勾选。

提交链路：业务按钮 -> 遍历selectedMap-> 得到所有选中行做批量操作。

三条链路彼此独立，selectedMap是唯一的数据源。这样排序、筛选、分页、跨页全选都只是围绕selectedMap做读写。还有一个小设计值得注意：selectedMap的value我会存{...row}快照，而不是直接存原行引用。原因有两个，一是防止后面对原行数据做修改时污染已选数据，二是提交时拿到的字段齐整，不会出现“勾选时明明有手机号，提交时对象里没有”的灵异事件。

3. 手动管理跨页选中的完整实现

下面这套实现，是我们在一个用户量万级的中后台项目里跑过一年的方案，按步骤复制就能用。我分三块讲：模板和数据结构怎么搭、勾选和取消怎么处理、翻页恢复有哪些细节必须注意。

3.1 模板与数据结构搭建

先看模板。注意我这里特意没用reserve-selection，selection列的代码和普通表格没有任何区别：

<template> <div class="user-table-wrapper"> <el-table ref="tableRef" v-loading="loading" :data="pageData" row-key="id" :row-class-name="rowClassName" @select="handleSelect" @select-all="handleSelectAll" > <el-table-column type="selection" width="55" /> <el-table-column prop="name" label="姓名" min-width="120" /> <el-table-column prop="phone" label="手机号" min-width="140" /> <el-table-column prop="dept" label="部门" min-width="120" /> <el-table-column prop="createTime" label="创建时间" min-width="170" /> </el-table> <el-pagination class="table-pagination" background layout="total, prev, pager, next, sizes" :current-page="page" :page-size="pageSize" :total="total" @current-change="handlePageChange" @size-change="handleSizeChange" /> </div> </template>

再定义数据结构。这里我推荐用Map而不是普通对象，因为Map对key的类型没有限制，插入顺序也好控制，遍历性能也比对象好：

export default { data() { return { page: 1, pageSize: 50, total: 0, loading: false, pageData: [], // 跨页选中的核心数据结构 // key: row-key 对应的字段值，例如 id // value: 行数据快照 { ...row } selectedMap: new Map(), // 防止恢复勾选时触发 select/select-all 事件导致死循环 isRestoring: false, }; }, };

这里有两个容易忽略的设计。

一个是isRestoring标志位。没有它，restoreSelection里调toggleRowSelection会触发@select事件，handleSelect又把数据写进selectedMap，而selectedMap变动如果又引起别的地方重新渲染，就会出现事件风暴，轻则选中状态错乱，重则直接栈溢出。我在刚实现这套逻辑时就没有标志位，页面一翻页就卡死，后来排查半天才找到是这里互相触发。

另一个是Map的value为什么要用{ ...row }而不是直接存row。前面提过，这是为了防污染。举个例子，用户在第1页勾选了一行，然后表格发请求刷新了列表，第1页的这行数据可能被新对象替代。如果你存的是旧引用，提交时拿到的内容还是旧的，反而没问题；但如果你在勾选后某个弹窗里修改了原行数据（比如改状态字段），旧引用对应的对象会和列表里显示的不一致。存快照就能保证selectedMap里永远是你勾选那一刻的状态，可控性最强。

3.2 勾选、取消勾选、全选的处理逻辑

勾选和取消走的是@select事件。这个事件回调里有两个参数：selection（变化后所有选中行的数组）和row（当前操作的那一行）。要判断是勾选还是取消，最简单的方法就是看row还在不在selection里：

handleSelect(selection, row) { // 恢复勾选期间触发的事件直接忽略 if (this.isRestoring) return; const key = row[this.rowKey]; const isSelected = selection.includes(row); if (isSelected) { // 勾选：写入快照 this.selectedMap.set(key, { ...row }); } else { // 取消：删除key this.selectedMap.delete(key); } }

这里有个细节值得说明：selection.includes(row)依赖的是“操作的行对象引用”。Element UI在渲染时用的是pageData里的行对象，你操作时传入的row也是同一个对象引用，所以includes能正确判断。如果因为某些原因你发现includes不准（比如对行对象做过浅拷贝），可以改成用key判断：

const isSelected = selection.some(item => item[this.rowKey] === key);

两条路都对，选一个顺手的即可。

全选和取消全选走的是@select-all事件。它只有一个参数selection，也就是操作后当前页选中行的集合。全选时，selection包含当前页所有行；取消全选时，selection为空数组。但这里有个大坑，我必须单独强调一下：Element UI的表头全选checkbox，点击一次在部分选中状态下会执行“先清空再全选”两个动作，也就是说selection参数会经历“空数组 -> 全部行”的过程。你在二次点击时，如果拿selection直接覆盖selectedMap，会把之前所有页的选中都清掉。所以处理@select-all一定要用“增量合并”而不是“整体覆盖”：

handleSelectAll(selection) { if (this.isRestoring) return; // 判断当前是“全选”还是“取消全选” // 全选时，当前页的每一行都应该在 selection 里 const isAllSelected = this.pageData.every(row => selection.includes(row)); this.pageData.forEach((row) => { const key = row[this.rowKey]; if (isAllSelected) { // 全选：把当前页所有行写入Map this.selectedMap.set(key, { ...row }); } else { // 取消全选：把当前页所有行从Map中删除 this.selectedMap.delete(key); } }); }

这段代码的关键在于isAllSelected的判断。它不关心selection经历过几次变化，只看当前这一帧的selection是否覆盖了pageData全部行。这样写，无论用户在什么选中状态下点全选，结果都是稳定的：要么把这页所有行合并进全局，要么把这页所有行从全局移除，其他页的选中不受影响。

3.3 翻页后恢复勾选的细节：不能用旧引用

翻页或改变每页条数后，pageData会被新的数据覆盖。此时表格本身是不带任何选中状态的，需要我们在数据到位后手动恢复。恢复逻辑放在loadPage的末尾：

async loadPage() { this.loading = true; const { list, total } = await fetchUserList({ page: this.page, pageSize: this.pageSize, }); this.loading = false; this.pageData = list; this.total = total; // 数据到位后恢复勾选 this.restoreSelection(); }, restoreSelection() { if (!this.$refs.tableRef) return; this.isRestoring = true; this.$nextTick(() => { this.pageData.forEach((row) => { const key = row[this.rowKey]; if (this.selectedMap.has(key)) { this.$refs.tableRef.toggleRowSelection(row, true); } }); this.isRestoring = false; }); }

这个restoreSelection是整个方案里最容易写错的地方，我几乎每次评审都能看到同事在这里踩坑。最常见的一个错误是：把selectedMap里存的旧行对象直接传给toggleRowSelection，而不是用当前pageData里的行对象。比如：

// 错误示例 this.selectedMap.forEach((row) => { this.$refs.tableRef.toggleRowSelection(row, true); });

这样写，翻页后表格根本不会有任何勾选。原因在于toggleRowSelection内部会拿传入的行和当前data中的行做匹配，由于你传的是旧页面的行对象引用，新pageData里每一行都是新创建的对象，引用对不上，组件认为“这一行不在表格里”，自然不会勾选。正确做法永远是遍历当前pageData，从selectedMap里查key，然后再回设。

另外，restoreSelection里this.$nextTick也是必须的。因为this.pageData = list之后，Vue需要等到DOM更新完，表格内部的data属性才会同步成新数据。如果不等nextTick，直接遍历pageData调toggleRowSelection，此时表格内部可能还在处理旧数据，会出现恢复失败或状态残留。

还有一个性能问题容易被人忽略：当一页有50条数据，循环调toggleRowSelection50次，每次都会触发一次表格内部的选中状态更新。如果回显逻辑还触发了@select事件，即使有isRestoring拦截，也会白白多走一轮方法调用。所以建议在restoreSelection开头就置isRestoring = true，nextTick的回调里循环完再置回false，把整个恢复过程隔离成一次“静默操作”。

3.4 清空全部与提交数据

跨页全选的方案里，这两个方法可以说是“配套服务”，缺一个都难受。

清空全部，指的是把selectedMap清空的同时，把当前页表格上可见的勾选也全部取消：

clearSelection() { // 清空业务层的选中集合 this.selectedMap.clear(); // 清空当前页表格可见的勾选 this.$nextTick(() => { this.$refs.tableRef.clearSelection(); }); }

这里要注意顺序：先清selectedMap，再调clearSelection()。因为clearSelection()会触发@select/@select-all事件，如果此时selectedMap还没清空，事件回调里会往Map里写入当前页所有行的key，导致“清空失败”。反过来，先清Map再清表格，事件触发了也无所谓，handleSelect和handleSelectAll判断到selectedMap已经没有对应key，自然不会写入。

提交数据时，把selectedMap的values取出来就行：

function handleSubmit() { if (this.selectedMap.size === 0) { // 给个提示，别让用户直接提交空数据 this.$message.warning('请先勾选要处理的用户'); return; } const selectedRows = Array.from(this.selectedMap.values()); // 调用批量接口 await batchOperation(selectedRows); }

如果你要按勾选顺序提交，Map本身会维护插入顺序，Array.from(this.selectedMap.values())拿到的数组基本就是用户勾选的先后顺序。但如果你中途删掉某个key再重新添加，Map会把它放到最后，这一点如果业务要求严格按操作顺序，需要额外维护一个orderList数组来记录，这里就不展开写了。

4. 一不留神就翻车的边界情况

跨页全选实现出来只是第一步。真正决定方案好不好用的，是它在各种异常场景下能不能稳住。下面这几个边界情况都是我在真实项目里被问过、被投诉过、现场排查过的，每个都值得拿出来单独说。

4.1 排序筛选后的选中语义问题

先给结论：跨页全选和排序、筛选不是天然兼容的，你必须先和产品经理确认“已选”到底代表什么语义。

我遇到的真实需求是这样的：用户在第1页勾了3个人，然后在搜索框里输入“离职”，点击查询，列表变成了离职员工，之前勾选的3个人不在结果里。此时界面上“已选3人”是否还应该显示？如果显示，用户可能看不到自己选了谁，很容易误解成“这3人是当前条件筛选出来的结果”；如果不显示，但提交时又把3个人带上，用户会在最后一步觉得莫名其妙。

后来我们定的方案是：所有筛选、排序操作都不会自动清空selectedMap，但会在表格上方浮动一条提示：

已选 N 人（当前查询条件下显示 M 人），操作将作用于全部已选。

同时提供“清除已选”按钮。这条提示的M怎么算？就是当前pageData里有多少行的key命中selectedMap：

const currentPageSelectedCount = computed(() => this.pageData.filter(row => this.selectedMap.has(row[this.rowKey])).length );

这样用户对“哪些选中可见、哪些不可见”一目了然，投诉率直线下降。另外，如果你的业务在筛选后确实希望“只作用于当前条件下的选中”，那就改成筛选时自动调用clearSelection()，并在筛选组件上给一个明显的“已有选中数据，切换筛选将清除”的提示。

4.2 排序重排与数据刷新的竞态问题

中后台列表几乎都有排序。点表头排序后，后端重新返回列表，此时pageData的数组顺序变了，但行的id没变。只要我们的回显逻辑基于key而不是基于顺序，排序后选中状态就能正确恢复。这里有个问题反而比排序本身更隐蔽：连续操作导致的接口竞态。

举个具体场景：用户在第1页卡顿的情况下连续点了第2页、第3页，前端会发出两次分页请求，后一次响应覆盖前一次。如果两次请求之间网络速度差异大，可能出现第2页的响应比第3页晚到，最后表格停在“page=3”的翻页指示器上，但展示的却是第2页的数据。这时候restoreSelection恢复的是第2页的选中，页面状态混乱。

解决竞态的标准做法是给请求编号，只有最新编号的响应允许覆盖数据：

data() { return { querySeq: 0, }; }, async loadPage() { const currentSeq = ++this.querySeq; this.loading = true; const { list, total } = await fetchUserList({ page: this.page, pageSize: this.pageSize, }); this.loading = false; // 过期响应直接丢弃 if (currentSeq !== this.querySeq) return; this.pageData = list; this.total = total; this.restoreSelection(); }

这个querySeq字段我在所有分页接口里都会加，成本几乎为零，但能防住绝大部分连续翻页、连续筛选造成的状态错乱。有时候用户反馈“表格偶尔显示和翻页按钮对不上”，十有八九就是缺这个。

4.3 表格销毁与账号切换时残留脏数据

后台系统经常有切换部门、退出登录、弹窗关闭等场景，表格组件被销毁或v-if置为false。如果selectedMap是页面级data，组件销毁时Vue会一起回收，问题不大。但如果表格在弹窗里，弹窗关闭后selectedMap还在父组件内存里，重新打开弹窗时，上一次的选中数据会残留在Map里。表现就是：用户这次打开弹窗，什么都没勾，提交的时候却提示“已选50人”。

这个问题我建议在进入表格页面前统一初始化selectedMap，并在关闭时清理：

openDialog() { this.selectedMap.clear(); this.dialogVisible = true; }, closeDialog() { this.dialogVisible = false; this.selectedMap.clear(); if (this.$refs.tableRef) { this.$refs.tableRef.clearSelection(); } }

这里的核心原则是：selectedMap的生命周期必须和业务会话一致，不能比表格组件更长。如果你把Map定义在全局store里，记得在退出相关业务模块时手动清空，不然这次选中的数据会跟着用户跑到下一个业务里去。

4.4 alert、messagebox、批量操作之后的选中保持问题

还有一种情况，用户勾选了几十行，执行批量操作后，接口报错了。此时要不要清除选中？不同业务的答案完全不同。我的经验是：操作失败时必须保留选中，操作成功时可以保留也可以清除，但必须给用户明确的反馈。很多系统采用“执行后自动清空”，结果接口超时，用户还得重新一页一页翻回去再勾选，体验极差。

我会把“提交”和“清空”拆成两个动作，只在批量操作成功且用户确认不再处理其余数据时才清空。另外，像MessageBox.confirm这类全局弹窗，如果用户点击“确定”后，我们把selectedMap清空了，后续弹出的成功提示就别再依赖这个Map显示数量，否则会出现“已选0人但提示成功操作3人”的笑话。

5. 跨页全选配套的体验优化与性能保障

模块跑通之后，就要考虑把它做得更好用、扛得住数据量了。这一部分我会结合表格滚动条、滚动条宽度、4000条假数据、组合筛选、获取列宽这几个中后台里经常连在一起出现的问题，逐个讲我在项目里的处理方案。

5.1 已选N条提示条与表格的联动布局

跨页全选之后，产品大概率会要求“在表格上方显示已选N条”。这个提示条最怕两件事：一是翻页后数字不更新，二是和表格列对不齐。

数字更新好办，用Map的size或者一个响应式的selectedCount就能实时显示。关键是布局对齐。有些设计会把提示条放在表格上方，里面还有“清除”按钮。如果表格开启了固定列，提示条的左边缘会和表格左边缘对齐，看起来是整齐的。但如果提示条里还有“查看已选”之类的下拉面板，它的宽度又不能超过表格本身。

我的做法是：给表格外层套一个.table-container，提示条放在容器内、表格之上，宽度设成100%，再配合box-sizing: border-box和表格本身的border设置，基本能保证视觉对齐。如果提示条需要对齐到某个具体列（比如对齐操作列），就得获取列宽了，这个我会在第5.4节专门讲做法。

5.2 大数据量下表格滚动条和固定列的性能细节

再来说热词里那个“el-table显示4千条假数据”。我先给一个个人建议：不要真的在一个页面上让el-table渲染4000行。很多人做原型时喜欢Array.from({ length: 4000 }, ...)生成假数据铺满表格，看着很震撼，但el-table并不是虚拟滚动表，4000行全部渲染会导致DOM节点爆炸，滚动条拖起来掉帧，勾选checkbox更是卡到没法用。

如果只是做演示，想要“一屏滚到底”的效果，比较简单的方法是给表格设置固定的height或max-height，让el-table自己产生内部滚动条：

<el-table :data="pageData" height="600" row-key="id"> <!-- columns --> </el-table>

这样做表格内部滚动，DOM渲染仍然只处理可见区域之外的滚动容器结构，虽然4000行全量渲染依旧存在，但至少不会撑满整页。屏幕高度有限，用户滚动的体验会好不少。

但如果你要的是真正的4000行流畅滚动，我只能说el-table做不到，得换支持虚拟滚动的方案，比如第三方table组件。跨页全选这套手动Map管理的逻辑和那些表格组件同样适用：你只需要把“表格组件的事件回调”替换成对应组件提供的@select/@select-all事件即可，selectedMap的核心设计不用变。

滚动条宽度的问题也要留个心。el-table开启固定列后，右侧会出现一个滚动条，当滚动条和固定列重叠时，表头和表体的列宽容易对不上，尤其是在窗口尺寸变化、表格宽度被百分比控制时。我在项目里遇到过一次：表格右侧固定了“操作”列，但横向滚动条被操作列遮住了一半，用户很难拖动。除了调整固定列宽度、给滚动条留位置之外，还可以在表格数据变化后主动调用一次：

this.$nextTick(() => { this.$refs.tableRef.doLayout(); });

doLayout()是el-table的实例方法，会重新计算列宽和布局。列宽对不齐、滚动条错位、固定列错位这些问题，在数据异步加载后经常出现，调一下基本都能解决。注意一定要放在nextTick里，否则DOM还没更新完，重新计算的是旧布局。

5.3 组合筛选组件和跨页全选的联动策略

大多数中后台表格上方都挂着组合筛选组件：关键字输入框、部门下拉、状态多选、日期范围。筛选一多，跨页全选的交互就复杂了。

我踩过的坑是这样的：用户在“全部状态”下勾了100人，然后选择“在职”状态筛选，此时列表只显示在职用户，之前的100人里有80人还在Map里，但列表里看不全。用户并不知道这100人里有20人是离职的，于是点击“全选”想继续把在职的都选上，结果100 + 全部在职，数量远大于预期。

处理这种联动，我总结出一个比较稳的交互模型：

• 筛选条件变化时，不自动清空selectedMap，但提示条上明确展示“已选N人（含当前筛选条件之外的M人）”。
• 如果用户希望只选当前结果集，可以先点“清除已选”，再重新勾选。
• 如果点击表头全选，只把当前结果集合并进selectedMap，不影响其他条件里的已选数据。
• 提交时提示“将处理全部已选N人”，并列出前几条和后缀“等N人”。

这个方案虽然不能让所有产品经理满意，但它在“数据安全”和“操作效率”之间做到了均衡，至少不会出现用户不知道自己在操作什么的情况。

组合筛选组件还会带来一个技术点：筛选条件在组件内部，但表格数据请求需要一个统一的参数对象。建议把筛选表单的model放在一个独立的computed或ref里，在loadPage里把它展开到请求参数中，避免每个筛选控件单独修改请求参数，保证跨页全选时重新请求的数据和筛选条件总是对应的。

5.4 获取列宽做自定义表头的对齐计算

最后说一个相对进阶但很实用的点：获取el-table的列宽。为什么要获取列宽？因为当你想在表头上方加自定义内容，比如“批量操作栏”的下拉、筛选面板的位置定位、表头某个checkbox的样式定制时，只能用绝对定位或对齐计算，这时候列宽就是唯一的坐标系依据。

官方并没有直接暴露一个“获取某一列宽度”的实例方法，但我们可以从两条路拿到。第一条是通过组件的store：

const columns = this.$refs.tableRef.store.states.columns; columns.forEach((col) => { console.log(col.label, col.width, col.realWidth); });

col.width是用户显式设置的宽度，col.realWidth是经过计算后的真实宽度。固定列和自适应列在realWidth上更可靠。第二条是直接从DOM里量：

const ths = this.$refs.tableRef.$el.querySelectorAll('.el-table__header thead th'); ths.forEach((th) => { console.log(th.getBoundingClientRect().width); });

DOM测量方式最直观，但依赖样式渲染完成，通常也要包在nextTick里用。我一般优先用store.states.columns拿逻辑宽度，用getBoundingClientRect做最终校正。拿到的列宽可以用来给“表头全选”替代方案做精确的checkbox定位，或者做一个跟随表头横向滚动的“已选N人”操作条。

顺带说一个列宽相关的高频bug：动态切换列的显示隐藏时，表格列宽会错乱。这是因为v-if变更后，表格内部的列缓存没有自动清理。解决方式是：给表格加key，让列配置大幅变化时重建组件，或者手动doLayout()重新排布。如果列切换频繁、性能要求高，优先doLayout；如果列配置切换不频繁，直接重建组件最稳，反正有selectedMap兜底，组件重建了选中数据也不会丢。

结尾

跨页全选这个功能，代码量不大，但牵扯到的边界场景一点也不少。我做下来最大的体会是：不要和表格组件较劲，要让组件只负责它擅长的事——展示和交互；真正需要长期保存的数据，一定要握在自己手里。这也是为什么整篇文章花了大力气讲selectedMap的设计，而不是教你怎么改Element源码或者钻reserve-selection的空子。

最后再分享一个我在实际项目中验证过的小技巧：如果你是用Vue3 + Element Plus，这套方案的代码风格基本不用变，唯一要注意的是toggleRowSelection的第三个参数在不同版本里有差异，恢复勾选时记得nextTick和isRestoring这两个保险一起上，能帮你省掉大半查bug的时间。

还有一个很容易被忽略的点，就是测试。跨页全选涉及分页、筛选、排序、批量操作、失败重试等场景，手工点几遍很难覆盖全。我建议用无头浏览器或者自动化测试把“跨页勾选 -> 翻页 -> 回显 -> 提交”这样一条主链路固定下来，每次发版前跑一遍。别问我为什么这么建议，我吃过一次线上漏测的亏，那次就是筛选后全选计数不对，用户反馈刷了一屏。