必须按 thead → tfoot → tbody 顺序书写，这是 HTML 规范强制要求，关乎渲染逻辑、打印分页、可访问性及 JS DOM 一致性，顺序错误将导致语义失效、读屏错乱、打印缺失和调试困惑。
必须按 thead → tfoot → tbody 顺序写，否则语义失效、打印错乱、可访问性工具读错。
为什么tfoot要写在tbody前面
不是“习惯”，是 HTML 规范明确要求的渲染逻辑依赖：
- 浏览器在解析时，会优先渲染
thead和tfoot，让表头和汇总行尽快可见——尤其当tbody数据量大、加载慢时，用户能立刻看到“这是什么表”“总共有多少” - 打印分页时，每页顶部重复
thead、底部重复tfoot，前提是它们在源码中前置；否则某些浏览器（尤其是旧版 Edge 或打印预览）可能只在第一页显示tfoot - JS 访问
table.tFoot返回的是 DOM 中声明的位置，但如果写在tbody后，浏览器虽会自动“挪到前面”渲染，DOM 树和 JS API 就不一致了，容易引发调试困惑
thead、tbody、tfoot 的嵌套与内容约束
三者都必须是 <table> 的直接子元素，且各自内部至少含一个 <tr>：
-
thead只能放表头行，用<th>，不能塞数据或空<tr>；空thead会导致 HTML 验证失败 -
tbody是唯一允许重复出现的区域（比如多组分类数据），但每个tbody必须有完整列数，不能靠colspan“假装对齐” -
tfoot全局只有一个，作用于整个表，不是每个tbody配一个；即使有多个tbody，tfoot也只出现在最后汇总位置 - 所有区域的列数必须严格一致：如果
thead有 4 个<th>，每个tbody的<tr>也得有且仅有 4 个<td>（或通过colspan/rowspan合理合并）
CSS 滚动与样式控制的实际坑点
想实现“固定表头 + 可滚动主体”，光靠 position: sticky 不够稳定，尤其在 Safari 或移动端：
立即学习“前端免费学习笔记（深入）”；
- 最稳妥做法是给
tbody设display: block; max-height: 300px; overflow-y: auto，同时确保thead保持display: table-header-group - 但一旦
tbody变成block，其子<tr>默认变成display: block，列宽立刻崩坏——必须显式重置：tr { display: table-row; }、td, th { display: table-cell; } -
tfoot在滚动场景下容易被忽略：它默认随tbody一起滚动；若需固定在底部，得配合position: sticky; bottom: 0，但要注意它和thead的 z-index 冲突，且部分安卓 WebView 不支持sticky在tfoot上生效
可访问性与打印的隐性依赖
屏幕阅读器和打印机的行为，完全基于这三个标签的正确使用：
- 读屏软件会把
thead内容缓存为“列名”，每读一行tbody数据前自动播报对应th文字（如“姓名：张三”）；顺序错乱或缺失thead，就会变成“第一列：张三”，毫无意义 - Chrome/Firefox 打印时自动跨页重复
thead和tfoot，但前提是它们在源码中位于tbody之前；否则打印结果里可能只有第一页有表头，最后一页才有汇总行 - 如果用 JS 动态生成表格，务必保证插入顺序仍是
thead→tfoot→tbody，不要依赖“浏览器会修复”——a11y 工具和打印引擎不看渲染结果，只读源码顺序
真正难的不是写对标签，而是记住：它们不是装饰，而是浏览器和辅助工具赖以工作的契约。顺序错一位，可访问性就断一节，打印就少一行，JS 获取结构就多一层歧义。
