必须用单次filter()回调合并所有条件：每个条件默认true（不限制），用&&连接布尔表达式，避免链式filter或嵌套if导致漏行或错显；精确匹配需清洗文本后用===比对，多输入框共用防抖后的统一过滤回调，且仅遍历tbody tr确保数据行安全。
多条件“与”逻辑怎么写才不漏行也不错显
必须用单次 filter() 回调合并所有条件，而不是链式调用或嵌套 if。链式 .filter().filter() 会反复创建新数组，且中间某次过滤把行筛没了，后续条件就无从判断；嵌套 if 容易漏掉“全部条件都满足”的语义。
正确做法是：遍历每行时，对每个条件单独计算布尔值，再用 && 连接：
const matchesDept = deptInput.value ? row.cells[2].textContent?.trim().toLowerCase().includes(deptInput.value.toLowerCase()) : trueconst matchesRole = roleInput.value ? row.cells[3].textContent?.trim().toLowerCase().includes(roleInput.value.toLowerCase()) : true- 最终判断：
if (matchesDept && matchesRole) { tr.style.display = ''; } else { tr.style.display = 'none'; }
注意：每个条件默认返回 true（即“不限制”），避免空输入导致整行被隐藏。
怎么让“部门=市场部 且 角色=负责人”这种精确匹配生效
模糊匹配（includes）在多条件场景下容易误召——比如搜“负责”，会把“负责人”“副负责人”“责任”全拉出来。真要精确匹配，得用 === 或正则 ^keyword$，但前提是用户输入和单元格文本完全一致。
立即学习“前端免费学习笔记（深入）”；
更实用的做法是预处理单元格文本，再做等值比对：
- 提前统一清洗：
const cleanCell = cell.textContent?.trim().replace(/[\s\uFEFF\xA0]+/g, ' ')（合并多余空格、全角空格） - 输入框也做同样清洗：
const keyword = input.value.trim().replace(/[\s\uFEFF\xA0]+/g, ' ') - 然后用
cleanCell === keyword判断，比includes更可控
如果后端传的是枚举值（如 role: "team_lead"），前端最好也用 data-value 存真实值，比依赖显示文本更可靠。
input事件监听多个搜索框，怎么避免竞态和状态错乱
每个输入框单独绑 input 事件没问题，但回调里不能各自执行一次完整过滤——用户同时改两个框，后触发的那个会覆盖前一个的结果，造成“只响应最后一次输入”的假象。
必须把所有筛选条件集中读取、统一执行一次过滤：
- 所有输入框共用一个回调函数，比如
onFilterChange() - 函数内一次性读取：
const dept = deptInput.value; const role = roleInput.value; - 不要在每个
input里直接操作 DOM，先攒状态，再批量更新 - 加防抖仅针对整个筛选动作，不是每个输入框单独防抖：
clearTimeout(filterTimer); filterTimer = setTimeout(onFilterChange, 200);
否则会出现“刚输完部门，角色框还没输完，表格就刷了”，用户根本来不及填第二个条件。
为什么用 querySelectorAll('tbody tr') 而不是 getElementsByTagName('tr')
getElementsByTagName('tr') 会把 <thead> 和 <code><tfoot> 里的行也抓进来，甚至可能混入没闭合的 <code><tr> 或浏览器自动补的空行。一旦你对第 0 行（表头）执行 <code>row.cells[0].textContent，要么报错，要么匹配到“ID”“姓名”这些标题字，搜“ID”反而把所有行都显示出来。
显式写 <tbody> 标签，并用 <code>table.querySelectorAll('tbody tr') 是唯一稳妥方式：
- 确保只遍历数据行，不碰表头
- 避免旧版 Safari 或手写省略
<tbody> 的 HTML 出现解析差异 <li>配合守卫判断：<code>if (!row.cells.length) return;，防止空<tr> 导致 <code>cells[0]报错这个细节在调试时经常被忽略，但一旦表格结构稍复杂（比如带合并单元格、动态插入行），
getElementsByTagName('tr')就开始不可靠。
