万级表格勾选不卡顿的关键是事件委托、Set管理选中ID、批量操作DOM、禁用过渡动画；清空selectedIds而非重置checkbox以保证业务状态一致；导出用Web Worker分片或后端流式生成；indeterminate需JS动态设置。
怎么让表格支持万级数据的勾选而不卡顿
直接用 querySelectorAll 遍历所有 tr 绑定事件或读取状态，万行表格会明显卡顿。关键不是“能不能勾”，而是“勾的时候别让主线程等”。
- 用事件委托：把
change事件监听在tbody上，通过e.target.matches('input[type="checkbox"]')判断是否点击了复选框，避免为每行单独绑定 - 全选逻辑不遍历 DOM：维护一个
Set存已选 ID（如selectedIds = new Set()），勾/取消时增删即可；渲染时靠dataset.id和这个集合比对来设checked - 避免实时同步 UI：翻页或搜索后，不要重绘整张表，只批量操作
input.checked属性——DOM 更新本身比 JS 运算慢得多 - 禁用动画和过渡：
table * { transition: none !important; }，尤其在勾选频繁时能明显提速
为什么批量操作后要清空 selectedIds 而不是重置 checkbox
清空 selectedIds 是必须的，但仅靠 el.checked = false 不够——它只改 DOM 状态，不清理业务层的选中记忆，后续翻页、筛选、排序都会出错。
- 接口返回成功后，立刻执行
selectedIds.clear()，而不是循环设checked = false；后者在大表里可能触发大量重排 - 如果用了分页，还要同步清空当前页缓存（如
currentPageSelection = []），否则下一页进来时 checkbox 状态仍残留 - 权限控制项（如灰色 disabled 复选框）不能进
selectedIds，添加时需先判断!el.disabled，否则会导致“已选 N 条”但实际可操作数更少
Excel 导出时怎么避免内存爆炸
导出万行数据时，直接 JSON.stringify 或拼 HTML 表格再转 Excel，极易触发内存溢出或主线程冻结。核心是避开主线程搬运原始数据。
- 必须用
Web Worker：主线程只传ArrayBuffer，Worker 内用xlsx.read(data, { type: 'array' })解析，禁用样式、图表、公式（cellStyles: false, cellFormula: false） - 不要一次性 postMessage 大数组：解析完后，按 2000 行一组分片，用
worker.postMessage({ chunk: rows, index: i }, [])逐批传回，主线程拼接 - 后端导出更稳：前端只传选中 ID 数组（如
item_ids[]=1&item_ids[]=2），由后端查库、流式写入 Excel 并返回下载链接，避免前端扛解析压力
全选 checkbox 的 indeterminate 怎么设才不出错
indeterminate 是纯视觉态，不能靠 HTML 属性设置，且设了不会触发 change 事件——很多开发者卡在这里，导致全选框状态和实际勾选数不一致。
立即学习“前端免费学习笔记（深入）”；
- 必须用 JS 设置：
selectAllCheckbox.indeterminate = (checkedCount > 0 && checkedCount ，注意顺序：先设 <code>indeterminate，再设checked（否则会被覆盖） - 监听的是每个行 checkbox 的
change，不是click；键盘空格切换也得生效，click无法捕获 - 动态增删行时，要重新计算
totalRows（过滤后可见行数），不能硬编码表格原始长度
真实批量操作的复杂点不在勾选动作本身，而在状态生命周期管理——从勾选、翻页、筛选、导出到最终提交，每一步都可能让已选 ID 和 UI 显示脱节。最容易被忽略的是：权限禁用项是否参与统计、分页缓存是否及时清理、Worker 解析失败后有没有 fallback 提示。这些细节没兜住，用户点十次「删除」可能只删掉三条。
