tbody必须显式写出，否则CSS选择器失效、JS无法索引、打印和可访问性异常；正确做法是无论有无thead都显式包裹数据行，并支持多tbody语义分组。
tbody 必须显式写出，不能依赖浏览器自动补全
很多人写表格时只写 <thead> 和一堆 <code><tr>，以为浏览器会“智能处理”。实际上，HTML 解析器虽会隐式插入 <code><tbody>，但这个节点不响应 CSS 选择器（比如 <code>tbody tr:nth-child(odd)）、无法被 JS 正确索引（table.tBodies[0] 返回空），且在动态插入行时容易错位到 <thead> 后面却不在任何分组内。
<p>正确做法是：无论有没有 <code><thead> 或 <code><tfoot>，只要表格有数据行，就显式包裹一层 <code><tbody>。
<ul>必须成对出现：<code><tbody> 和 <code>
，不能自闭合 <tbody></tbody>
<tbody> 当作警告甚至错误
<h3>多个 tbody 的真实用途：按逻辑分组，而非分页或懒加载</h3>
<p>一个 <code><table> 可以包含多个 <code><tbody>，但目的不是“让长表格滚动更快”，而是语义分组。比如销售数据按季度、用户列表按状态（激活/禁用）、权限配置按角色等级。
<p>这样做的好处是：CSS 可以单独控制某组样式（<code>.q1 tr { background: #f0f9ff; }），JS 可精准操作某块数据（document.querySelector('.q2').remove()），打印时也能按组折叠或高亮。
立即学习“前端免费学习笔记（深入）”；
- 多个
- 斑马纹必须写成
tbody tr:nth-child(even)，写成tr:nth-child(even)会把表头也染上色 - JS 插入新行时，永远指向
document.querySelector('tbody')或table.tBodies[0]，而不是table本身——否则新行可能插到<tfoot> 后面 <h3>打印和可访问性场景下 tbody 不可省略</h3> <p>没有显式 <code><tbody>，<code><thead> 和 <code><tfoot> 在打印时无法跨页重复；屏幕阅读器也无法准确识别“哪些是标题、哪些是数据”，尤其当表格有合并单元格或复杂结构时。 <ul>每个 <code><th> 应加 <code>scope="col"，首列<td> 加 <code>scope="row"，配合<thead> + <code><tbody> 才能被读屏软件连读为“姓名 张三，年龄 25” <li>打印 CSS 中，<code>@media print { thead, tfoot { display: table-header-group; } }只在显式存在<tbody> 且顺序正确（<code><thead> → <code><tfoot> → <code><tbody>）时才可靠生效 <li>服务端渲染时，若条件渲染某组数据，应整块操作 <code><tbody class="status-active">，而不是只渲染其中的 <code><tr> —— 空 <code><tbody> 仍占流，可能干扰高度计算 tbody 的作用不是“让代码看起来更整齐”，而是让浏览器、CSS 引擎、辅助技术和 JS 运行时都能按预期理解表格结构。漏掉它，表面看不出问题，但所有依赖结构的操作都会在某个环节悄悄失效。</tbody>
<tbody> 必须是 <code><table> 的直接子元素，不能嵌套在 <code><div> 里 <li>不要用它实现“分段加载”——这会导致频繁重排，卡顿明显</li> <li>如果需要懒加载长表格，请用虚拟滚动 + 单个 <code><tbody> + <code>DocumentFragment 批量更新
tbody 影响 CSS 和 JS 的关键行为
<tbody> 不是透明容器，它自带 <code>display: table-row-group，一旦误设为 block 或 flex，内部的 <tr> 就会塌陷失效。同时，它的存在直接决定哪些样式能生效、哪些 JS 操作能命中目标。
<ul>固定表头时，<code><thead> + <code><tbody> 是前提：给 <code><tbody> 设 <code>max-height 和 overflow-y: auto，再配合 table-layout: fixed 和列宽控制，才能避免错位
