tfoot 必须写在 tbody 前面，这是 HTML 规范强制要求，关乎浏览器渲染逻辑、可访问性语义及 PDF 导出正确性；顺序错误会导致 DOM 与 API 不一致、屏幕阅读器误读、汇总行丢失等问题。
必须放在前面——不是“建议”，是 HTML 规范强制要求，浏览器解析逻辑和可访问性都依赖这个顺序。
为什么 tfoot 必须写在 tbody 前面
这不是为了“好看”或“习惯”，而是浏览器流式渲染和 DOM 构建机制决定的：
- 浏览器在解析 HTML 时，一旦遇到
thead就立即渲染表头，用户无需等待全部数据；tfoot提前声明，能让浏览器立刻预留页脚占位（比如“共 248 条”），哪怕tbody还在加载或 JS 动态填充中 - 打印分页时，只有
thead和tfoot写在tbody前，浏览器才保证每页都重复显示它们；顺序错乱会导致 PDF 导出库或旧版 Safari 直接忽略tfoot - 屏幕阅读器按 DOM 顺序读取表格结构，
tfoot错位会把汇总行误读成正文开头，破坏语义逻辑
tfoot 放在 tbody 后面会发生什么
表面看似乎“也能显示”，但背后隐患明显：
- 浏览器会自动把
tfoot节点“修正”到tbody前构建 DOM 树，但 JS 访问table.tFoot仍返回原始位置节点，导致 DOM 树与 API 返回值不一致 - 多
tbody场景下（如分组表格），tfoot只能有一个且作用于整个表；若写在某个tbody后，它可能被错误关联到前一个tbody，或被完全忽略 - 某些 PDF 生成库（如 Puppeteer 的旧版本、wkhtmltopdf）直接跳过位置错误的
tfoot，合计行彻底丢失
正确写法与常见陷阱
标准顺序是：caption → colgroup → thead → tfoot → tbody。注意几个硬约束：
立即学习“前端免费学习笔记（深入）”；
-
tfoot内部必须包含至少一个tr，不能直接放td或文本 - 列数必须与
thead和tbody严格对齐，否则可访问性工具报错，固定表头 JS 库（如 StickyTableHeaders）计算错位 - 不要用
display: flex或orderCSS 强行“调换”视觉顺序——tfoot的语义位置只由 HTML 顺序定义，样式干预无效且有害 - 动态插入时，JS 创建
tfoot后必须用insertBefore()插入到tbody前，而不是appendChild()到 table 末尾
最易被忽略的一点：即使你用现代框架（React/Vue）生成表格，只要最终输出的 HTML 中 tfoot 在 tbody 后，就已违反规范——框架不替你兜底语义结构。
