全选逻辑卡顿主因是DOM节点过多而非JS性能差，应采用事件委托、虚拟滚动、过滤disabled元素及后端代劳等方案优化。
全选逻辑卡顿是因为 DOM 节点太多，不是 JS 写得慢
几百个 <input type="checkbox"> 一渲染，浏览器就要创建对应数量的 DOM 节点 + 事件监听器，内存占用和样式计算直接翻倍。你用 querySelectorAll('[name="item_ids"]') 查一次就卡，不是因为选择器写错了，而是浏览器在遍历上万节点时根本来不及响应。
常见错误是：在数据加载完后立刻执行全选状态同步，比如 document.querySelectorAll('input[name="item_ids"]').forEach(...) —— 这行代码本身没问题，但当匹配结果有 5000+ 个元素时，它就成了性能瓶颈。
- 避免对所有 checkbox 逐个设
checked = true/false，改用setAttribute('checked', '')或removeAttribute('checked')并不比前者快，本质仍是遍历 - 不要在每次点击“全选”时都重新查一遍全部 checkbox，尤其在虚拟滚动或分页场景下，只操作当前可视区节点
- 禁用项（
disabled）必须从统计和操作中排除，否则会导致状态错乱——比如 100 条里有 5 条 disabled，全选后实际只勾了 95 个，但顶部 checkbox 却显示已全选
用事件委托代替每个 checkbox 绑定 change
给每个 <input type="checkbox"> 单独加 addEventListener('change', ...) 是最典型的性能陷阱。1000 个 checkbox 就绑 1000 个监听器，内存泄漏风险高，且动态插入的新项不会自动绑定。
正确做法是把监听器挂到父容器上，靠 event.target 判断是否为 checkbox：
立即学习“前端免费学习笔记（深入）”；
const container = document.getElementById('checkbox-list');
container.addEventListener('change', function (e) {
if (e.target.type === 'checkbox' && e.target.name === 'item_ids') {
updateSelectAllState(); // 只更新全选框状态，不操作其他 checkbox
}
});
注意：change 比 click 更可靠，能捕获键盘空格触发、JS 手动设置等所有状态变更路径。
- 别用
onclick替代onchange，用户按空格切换 checkbox 时不会触发 click - 父容器必须存在且稳定，不能是临时拼接的字符串模板；若用框架渲染，确保事件委托绑定时机在 DOM 挂载之后
- 如果 checkbox 分布在多个独立区域（如分页 tab），需分别为每个区域设委托，不能只绑一个全局容器
全选状态判定必须过滤 disabled 元素
判断“是否全选”的逻辑不能简单写成 checkedCount === totalCount。一旦页面中有权限控制导致部分 checkbox 加了 disabled，这个等式就失效了——被禁用的项不该参与“全选”语义。
正确统计方式是用 CSS 伪类过滤：
const allCheckboxes = document.querySelectorAll('input[name="item_ids"]:not(:disabled)');
const checkedCheckboxes = document.querySelectorAll('input[name="item_ids"]:checked:not(:disabled)');
const isAllSelected = checkedCheckboxes.length === allCheckboxes.length;
这个查询看似多了一次 DOM 遍历，但比在 JS 里手动遍历并判断 el.disabled 更快，因为浏览器原生支持 :not(:disabled) 的优化路径。
-
:not(:disabled)必须写在选择器末尾，否则可能匹配失败（如input:not(:disabled)[name="x"]不如input[name="x"]:not(:disabled)稳定） - 不要缓存
allCheckboxes结果，DOM 可能被外部脚本或权限逻辑动态增删 disabled 属性 - 反选操作（点击全选框时取反）比“设为 true/false”更安全，避免中间态残留：比如某项正在 disabled → enabled 切换过程中被误操作
万级 checkbox 必须放弃全量渲染
Element UI 的 el-checkbox-group 卡住不是组件问题，是浏览器对上万个 DOM 节点的天然限制。哪怕你把 JS 逻辑写得再精简，只要 DOM 存在，渲染、重排、事件系统就逃不开开销。
真实项目中可行的底线方案只有两个：
- 用虚拟滚动（virtualized list）：只渲染可视区域 ±10 行，滚动时动态替换 DOM，配合
IntersectionObserver或requestIdleCallback更新状态 - 改用
<select multiple>做筛选场景：原生控件性能远高于自定义 checkbox 列表，适合纯筛选、非批量操作场景
别试图“优化 checkbox 渲染”，那是对抗浏览器引擎。真正该花时间的是设计交互降级策略：比如搜索后只展示前 100 条可选结果，其余折叠进“更多”按钮；或者把批量操作拆成“按条件批量”而非“按行手动勾选”。
最常被忽略的一点：全选功能的本质不是“让用户勾选全部”，而是“让用户表达‘全部’这个意图”。这个意图可以由后端代劳——前端只传一个 select_all=true&filter=xxx，而不是把上万 ID 拼成字符串发过去。
