筛选后全选框状态失步的根本原因是DOM重绘导致NodeList缓存失效或name分组逻辑被破坏：display:none时querySelectorAll仍返回隐藏项，DOM重建则丢失事件与状态；需用data-filtered过滤、委托事件、手动维护indeterminate并校验可见项。
全选反选功能在多条件筛选场景下容易失效，根本原因不是 JS 写错了，而是筛选后 DOM 节点被重绘、querySelectorAll 缓存了旧 NodeList，或 name 分组逻辑被动态内容破坏。
为什么筛选后全选框状态失步？
多条件筛选通常用 display: none 或移除/重建 DOM 实现。前者会让 querySelectorAll('input[name="selected"]') 仍返回全部节点（包括隐藏的），后者则导致原绑定事件丢失、NodeList 失效。
- 筛选时若只改样式（如
style.display = "none"），全选逻辑仍会操作所有复选框，包括不可见项——这违反用户预期 - 若用 innerHTML 或模板引擎重绘 tbody，原
input元素被销毁，事件监听器和checked状态全部丢失 - 动态插入新行时没补全
name="selected"，导致新行不参与全选/反选
全选函数必须适配筛选态
不能无差别遍历所有 input[name="selected"]，得只操作当前可见且可交互的复选框。
- 给每行复选框加一个统一 class，比如
class="filter-item-checkbox"，筛选时对整行设hidden属性或data-filtered="true" - 全选函数里用
document.querySelectorAll('input[name="selected"]:not([data-filtered="true"])')过滤掉被筛掉的项 - 避免用
getElementsByClassName，它返回的是 live NodeList，筛选过程中可能被意外修改 - 如果用
display: none控制显隐，检查前先过滤：Array.from(boxes).filter(cb => window.getComputedStyle(cb.closest('tr')).display !== 'none')
反选逻辑必须跳过全选框本身
反选不是翻转“全选框的状态”，而是对每个有效复选框执行 cb.checked = !cb.checked。常见错误是没排除全选控件，导致点一次反选，全选框自己也被翻转。
立即学习“前端免费学习笔记（深入）”；
- 反选函数中明确限定目标：
document.querySelectorAll('input[name="selected"]:not([id="select-all"])') - 别用
click()触发切换——它可能触发两次 change；直接赋值cb.checked = !cb.checked - 翻转后必须重新统计：有多少个
checked为 true，是否全勾、全不勾、部分勾，再同步设置select-all.indeterminate和checked - 注意 disabled 状态：对
cb.disabled === false的才操作，否则会报错或覆盖禁用态
indeterminate 状态必须手动维护
浏览器不会自动判断“部分勾选”，这个中间态完全靠 JS 推算并设置。筛选后若忽略这步，全选框就永远卡在纯勾或纯空状态，失去语义。
- 每次子项 change 后，或全选/反选执行完，都要运行校验逻辑
- 先设
selectAll.indeterminate = false（清除残留），再根据统计结果设checked或indeterminate = true - 设
indeterminate = true时，checked值会被忽略，所以顺序不能反 - 不要依赖 CSS 伪类自动显示横线——
indeterminate是 JS 层状态，样式只是渲染结果
最易被忽略的一点：筛选前后，name="selected" 的复选框集合可能已变化，但全选框的 change 事件监听器还绑在老节点上。动态筛选场景下，要么每次重绘后重新绑定，要么把事件委托到父容器并用 event.target.matches('input[name="selected"]') 判断来源。
