tfoot必须写在tbody前面，因为HTML规范强制要求该顺序；浏览器解析时若发现tfoot在tbody后会自动重排DOM，导致CSS定位失效、JS节点顺序异常、打印错乱及首屏优化失败。
必须按 thead → tfoot → tbody 的顺序写，否则浏览器会自动重排 DOM，导致样式错乱、JS 获取节点顺序异常、打印失效。
为什么 tfoot 必须写在 tbody 前面？
不是“习惯”，是 HTML 规范强制要求。浏览器解析时一旦发现 tfoot 在 tbody 后，会把它从源码位置“拎出来”插到 tbody 之后——这个重排过程不可见但后果明确：
- CSS 中用
table > tfoot定位会失效（因为 DOM 结构已变） - JS 执行
table.tFoot或table.tBodies[0]仍能取到，但table.children顺序与源码不一致 -
@media print样式依赖结构语义，重排后页脚可能跑到中间页 - 大型表格中，本想利用“先渲染
tfoot再加载tbody”提升首屏感知速度，结果完全失效
thead / tbody / tfoot 各自的使用边界
它们不是可选装饰，而是语义分组容器，每个都有不可替代的作用：
-
thead：只能有一个，且必须包含至少一个tr；列标题用th，不是为了加粗，而是告诉辅助工具“这是维度标识” -
tbody：可以有多个（比如分页数据块），但不能嵌套；所有真实数据行必须放在这里，tr直接子元素只能是td或th（后者用于行标题） -
tfoot：只能有一个，且内容应是汇总、统计、说明类信息；colspan常用，但不要塞交互控件（如按钮），它不是操作区
常见错误现象与修复方式
实际开发中，这些坑几乎都源于“没当真对待结构”：
- 错误写法：
<table><tbody>...</tbody><thead>...</thead></table>→ 浏览器把thead移到最前，但 JS 拿table.children[0]仍可能是tbody（取决于解析时机） - 漏写
tbody：浏览器自动补一个空tbody，但你写的tr全被塞进去；后续用querySelector('tbody tr')能取到，但用table.tBodies[0].rows可能为空（如果源码没显式tbody） - 用
div替代tbody实现滚动固定表头 → 语义丢失，屏幕阅读器无法识别数据区域，打印时整块消失 - CSS 写
thead th { position: sticky; top: 0; }却无效 → 检查父级table是否设了border-collapse: collapse，以及tbody是否有display: block（这会破坏表格格式化上下文）
真正关键的不是“能不能用”，而是“结构一旦错，后续所有样式、脚本、无障碍、打印逻辑都会悄悄偏移”。哪怕只有一张报表页，也请从第一行就按规范写死顺序。
