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（这会破坏表格格式化上下文）

真正关键的不是“能不能用”，而是“结构一旦错，后续所有样式、脚本、无障碍、打印逻辑都会悄悄偏移”。哪怕只有一张报表页，也请从第一行就按规范写死顺序。