tbody是表格结构刚需而非可选包装，因隐式tbody无法被css/js稳定操作、影响屏幕阅读器语义、破坏打印分页及流式渲染，且固定表头、斑马纹等依赖其显式存在与正确嵌套。
必须显式写 tbody，不能依赖浏览器自动补全——否则 JS 操作、固定表头、打印分页都会出问题。
为什么 tbody 不是“可选包装”，而是结构刚需
浏览器确实会为没写 tbody 的表格自动创建一个 DOM 节点，但这个“隐式 tbody”无法被 CSS 选择器稳定命中，更无法被 JS 安全操作。比如 document.querySelector('tbody') 在省略标签时可能返回 null 或意外节点。
- 屏幕阅读器依赖显式的
thead/tbody划分来正确播报列与数据的语义关系； - 打印长表格时，只有显式
thead+tbody+tfoot（且顺序为thead→tfoot→tbody）才能让表头/页脚重复出现在每页； -
table.rows返回的是全部行（含表头、页脚），而document.querySelectorAll('tbody tr')才能精准拿到纯数据行； - 用
insertRow()往table上插行，行为不可控；但往document.querySelector('tbody')上插，位置和语义才确定。
tbody 分段加载的真实效果在哪体现
分段加载不是视觉动画，而是 HTML 解析流式渲染的底层机制：只要 tbody 开始标签已解析，其内部的 tr 就能边下载边显示，不用等整个 table 结束。
Html To Pdf
下载
使用 Puppeteer + Chrome 将 HTML 渲染为中文 PDF，自动处理图表等待、Tab 展开、动画、测高、白边消除、防分页，适用于看板、报表、网页和交互图表转 PDF。
- 仅在表格行数多（>50 行）、单行 HTML 较长、或网络慢时明显；小表格看不出区别；
- 多个
tbody可按逻辑分组（如“Q1 数据”“Q2 数据”），但每个tbody必须完整包含若干tr，不能跨tbody拆分一行； - 不要为了“看起来分段”而硬加
tbody——如果只有一组数据，一个tbody就够了； - 服务端模板（如 EJS、Django）中，务必把循环生成的
tr包在<tbody>...</tbody>内，而非直接塞进table。
CSS 和 JS 操作 tbody 的关键约束
固定表头滚动、动态排序、斑马纹这些常见需求，都卡在 tbody 的 DOM 定位和样式边界上。
- 给
thead th加position: sticky; top: 0之前，tbody必须有明确高度（如max-height: 400px）并设display: block或外层套div控制溢出； - 用
tbody tr:nth-child(even)实现斑马纹时，确保tbody是唯一父容器——如果tr直接在table下，伪类会从整个表格行计数，错乱； - JS 替换数据时，清空并重写
tbody.innerHTML是最安全的，避免手动removeChild遗漏或顺序错乱； -
colspan/rowspan跨行单元格必须严格落在同一tbody内，否则语义断裂，辅助技术无法关联。
最容易被忽略的一点：哪怕你只用一个 tbody，也必须和 thead、tfoot 同级直属于 table，且顺序固定为 thead → tfoot → tbody。DOM 构建顺序错了，打印和流式渲染就不可靠。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
