tfoot 必须写在 tbody 前面，这是 HTML 规范强制要求，关乎浏览器渲染逻辑、可访问性语义及 PDF 导出正确性；顺序错误会导致 DOM 与 API 不一致、屏幕阅读器误读、汇总行丢失等问题。
必须放在前面——不是“建议”，是 HTML 规范强制要求，浏览器解析逻辑和可访问性都依赖这个顺序。
为什么 tfoot 必须写在 tbody 前面
这可不是为了代码“好看”或者遵循某种“习惯”，其背后是浏览器流式渲染和 DOM 构建机制决定的硬逻辑：
- 浏览器解析 HTML 时，一旦遇到
thead就会立即渲染表头，用户无需等待全部数据加载完毕。同理，提前声明tfoot，能让浏览器立刻为页脚预留好占位（比如显示“共 248 条”），即便tbody的内容还在加载中，或者需要通过 Ja vaScript 动态填充。 - 在打印或生成分页时，只有将
thead和tfoot写在tbody之前，浏览器才能保证它们在每一页都重复显示。顺序一旦错乱，某些 PDF 导出库或旧版 Safari 浏览器可能会直接忽略tfoot。 - 屏幕阅读器等辅助工具会严格依照 DOM 顺序来解读表格结构。如果
tfoot位置错位，本应是汇总的信息会被误读为表格正文的开头，彻底破坏了表格的语义逻辑。
tfoot 放在 tbody 后面会发生什么
表面上看，似乎“也能正常显示出来”，但背后的隐患可一点都不少：
- 浏览器为了正确渲染，可能会自动将
tfoot节点在 DOM 树中“修正”到tbody之前。然而，Ja vaScript 通过table.tFoot属性访问时，返回的仍是原始位置的节点，这就导致了 DOM 树结构与 API 返回值不一致的诡异情况。 - 在多个
tbody的场景下（例如分组表格），tfoot只能有一个，并且作用于整个表格。如果将其写在某个tbody之后，它很可能被错误地关联到前一个tbody，甚至被完全忽略。 - 一些 PDF 生成库（比如 Puppeteer 的旧版本或 wkhtmltopdf）会直接跳过位置错误的
tfoot，导致至关重要的合计行在最终文档中彻底丢失。
正确写法与常见陷阱
标准的结构顺序非常明确：caption → colgroup → thead → tfoot → tbody。除此之外，还有几个硬性约束需要注意：
立即学习“前端免费学习笔记（深入）”；
tfoot内部必须包含至少一个tr行，不能直接放置td单元格或纯文本。- 其列数必须与
thead和tbody严格对齐。否则，不仅可访问性工具会报错，一些实现固定表头功能的 Ja vaScript 库（如 StickyTableHeaders）在计算时也会出现错位。 - 切勿试图使用
display: flex或order这类 CSS 属性来强行“调换”视觉顺序——tfoot的语义位置仅由 HTML 源码顺序定义，样式干预不仅无效，反而有害。 - 当需要动态插入表格脚部时，使用 Ja vaScript 创建
tfoot元素后，务必通过insertBefore()方法将其插入到tbody之前，而不是简单地用appendChild()添加到表格末尾。
还有一个最容易被忽略的关键点：即使你使用的是 React、Vue 等现代前端框架来生成表格，只要最终输出到浏览器的 HTML 代码中，tfoot 仍然位于 tbody 之后，那就已经违反了规范。框架本身并不会为你的语义结构错误兜底。
