最轻量方式是直接为tr绑定点击事件切换style.display；推荐用CSS class（如table tr.hidden{display:none!important}）控制显隐，支持批量操作和动画；动态过滤应使用data属性；隐藏tr时需避免破坏表格结构和边框样式。
点击行时如何用 JavaScript 切换显示/隐藏状态
直接给 tr 元素绑定点击事件，通过切换 style.display 实现显隐，是最轻量、兼容性最好的方式。注意别用 visibility: hidden，它仍占布局空间，用户会看到空白行。
常见错误是给整张表加事件监听却没做事件委托，导致动态插入的行无法响应。正确做法是监听 table 或 tbody，再用 event.target.closest('tr') 判断是否点中了行：
document.querySelector('table').addEventListener('click', e => {
const row = e.target.closest('tr');
if (!row) return;
row.style.display = row.style.display === 'none' ? '' : 'none';
});
- 必须检查
e.target是否为tr或其子元素，否则点到td内文字或空隙会失效 - 设为空字符串（
''）而非'table-row'，避免覆盖 CSS 中定义的display值（比如某些框架设为flex） - 若表格有表头
thead，建议排除：加条件!row.parentElement.matches('thead')
如何用 class 控制多行批量显隐且不影响原有样式
用 CSS class 控制比直接操作 style.display 更可控，尤其适合需要统一管理显隐逻辑或配合动画的场景。关键是把 display 声明写在足够具体的选择器里，避免被其他规则覆盖。
典型错误是只写 .hidden { display: none; }，结果被 table tr { display: table-row; } 这类更宽泛的规则压制。应提升选择器权重：
立即学习“前端免费学习笔记（深入）”；
table tr.hidden {
display: none !important;
}
- 推荐用
!important，因为内联样式和许多 UI 框架（如 Bootstrap）也会设置display - 批量操作时，用
document.querySelectorAll('.data-row')获取目标行，再遍历添加/移除hidden类 - 若需过渡效果，
display不支持动画，可改用max-height+overflow模拟，但仅适用于固定高度行
使用 data 属性标记行类型后按条件过滤显示
当需要按状态、分类或搜索关键词动态控制显隐（比如“只显示已发货订单”），硬编码 class 或逐个操作 tr 效率低且难维护。用 data- 属性存元信息，再结合 JS 过滤，才是可扩展的做法。
例如给每行加 data-status="shipped"，然后用 dataset.status 读取：
function showOnly(status) {
document.querySelectorAll('tr[data-status]').forEach(row => {
row.classList.toggle('hidden', row.dataset.status !== status);
});
}
showOnly('pending'); // 隐藏所有非 pending 行
-
data-属性名要小写、用短横线分隔（data-order-id），JS 中读取为row.dataset.orderId - 避免在循环中反复调用
querySelectorAll，应在函数外缓存节点列表 - 如果表格数据量大（>500 行），直接 DOM 操作会卡顿，应考虑虚拟滚动或分页
隐藏行后如何保持表格结构不塌陷
隐藏 tr 后，colspan、rowspan 和边框样式可能错乱，尤其当相邻行被隐藏时，边框合并（border-collapse: collapse）会失效，出现断线或加粗边框。
根本原因是浏览器渲染时跳过了隐藏行的盒模型计算。解决办法不是强行修复边框，而是确保显隐逻辑不破坏表格语义：
- 永远不要隐藏
thead或tfoot中的行——它们是结构性元素，隐藏会导致表头错位 - 若某行含
rowspan，隐藏它可能导致下方单元格上移，此时应同步隐藏受影响的跨行单元格，或改用 CSS Grid 替代表格布局 - 边框问题最简方案：给所有
td和th设置统一border，并取消border-collapse，用border-spacing: 0模拟合并效果
真正麻烦的不是怎么藏，而是藏完之后用户是否还能看清剩下内容的对齐关系——这点容易被忽略，但直接影响可用性。
