thead和th的区别：HTML表格表头结构、打印与粘性表头避坑

「标签 thead 与 th 的区别」这个问题我最早是在一次代码评审里被问住的。当时有人指着我写的一段表格代码说这里既然已经有 thead 了为什么每一行还要套 th是不是重复了我当场解释了半天后来发现对方越听越糊涂——因为我一直在讲“语义化”却没讲清最关键的一点这两个东西根本不在同一个层级上一个是装行的箱子一个是装字的格子把它们放在一起比较就像问“抽屉和文件夹有什么区别”。这个误会在大前端圈子里很常见写了两三年页面的人照样会把 th 当整行标题用或者在 thead 里塞 td然后疑惑为什么打印出来的表格每页都有表头、有的又没有。下面我把这几年在后台管理系统、数据报表、移动端卡片表格里积累的经验一次讲透从 DOM 解析、默认样式、打印行为、粘性表头实现到无障碍属性怎么配、哪些写法看着能用实际上会埋雷。不管你是刚学 HTML 表格的新人还是天天跟后台列表打交道的老手看完至少能避开九成跟表头有关的坑。1. 别再混淆了thead 是行组容器th 是表头单元格1.1 thead 的定位表格里的“分区”不是一个格子先把最硬的事实摆出来thead是表格的行组元素table row group它内部只能放tr它的作用是给整个表格划出一块区域告诉浏览器和辅助技术“这里放的是列标题行”。注意是“行”是复数概念一个 thead 里可以有多行 tr用来做多级表头。它自己不承载任何文字内容你往 thead 里直接写文字浏览器会把它甩到表格外面去。我在项目里经常用这个类比一张表格就是一栋楼thead / tbody / tfoot 是三块功能区——表头区、数据区、汇总区而 th 和 td 是每一块里的房间。你不会把“房间”和“功能区”放在一起比较哪个更好用它们本来就是包含关系。规范里对 thead 出现的位置是有明确约束的它必须写在 caption、colgroup 之后tbody 或 tr 之前并且一张表里至多一个 thead。这一点很多人不知道以为可以写两个表头组实际上规范只允许一个需要多行表头就在 thead 里堆多个 tr。还有个容易忽略的细节thead在 DOM API 里是有专属入口的。table.tHead直接返回第一个 thead 元素配套的还有tFoot、tBodies。这几个属性是 HTMLTableElement 上的老牌接口比你在那儿querySelector(thead)要直接得多也不会被后插入的 DOM 干扰。我写导出脚本、打印脚本时基本都用这套接口取结构。1.2 th 的定位一个单元格只是语义上代表“表头”th的全称是 table header cell本质是单元格跟td是同一层级的兄弟。区别只有两点语义上它被标记为“表头”样式上浏览器给了默认加粗居中。就这两点别的什么都不差——它一样能设 colspan / rowspan一样能放 div、按钮、输入框一样参与表格布局计算。正因为它是单元格所以 th 不一定非得待在 thead 里。这是最容易让人困惑的地方tbody里每一行第一个单元格如果是行标题比如“用户A”、“2024年第一季度”也应该用 th配scoperow。这种写法在数据报表里非常常见但很多人以为 th 只能出现在表头行于是改用 td 加粗直接把语义丢了。我给你一个判断标准简单粗暴但好用这个格子的内容是用来“描述别人的数据”的还是“本身就是要展示的数据”前者用 th后者用 td。列标题、行标题、分组小标题都属于前者。数值、日期、状态、操作按钮都属于后者。1.3 一张对照表把差异钉死光说容易飘直接上表对比。这张表我自己贴在团队文档里新人有疑问就让他看对比项theadth元素类别行组容器row group单元格cell直接子元素只能是tr任意流内容文本、div、按钮等默认displaytable-header-grouptable-cell默认样式无特殊视觉样式font-weight: bold 居中一张表允许数量至多 1 个不限按需能否出现在 tbody 内不能能作行标题DOM 快捷属性table.tHead无专属走rows[i].cells[j]主要价值分区、打印重复、列宽锚定语义标注、无障碍播报、样式钩子常见误用里面塞 td 或裸文本用来包裹整个表头行提示判断一段表格代码写没写对最快的办法是数一遍标签嵌套层级——table thead tr th 是四层任何一层错位都算结构问题。2. 浏览器怎么解析这两个标签从 DOM 树看真实结构2.1 自动补 tbody 的机制制造了“thead 可有可无”的错觉写表格的时候你可能注意到直接在table里写tr打开开发者工具却看到多出来一个tbody。这是 HTML 解析器的老规矩表格相关元素有一套专门的插入模式insertion mode遇到裸露的 tr 会自动包一层 tbody。这个行为从很早就存在一直保留到现在。关键点在于解析器会自动补 tbody但绝不会自动补 thead。你把 tr 直接写在 table 下得到的结构是 table tbody tr没有表头分区。这意味着那段代码没有“表头”这个概念打印时不会重复语义树里也没有 header 角色。这个不对称很容易让人误判。我见过有人写了一段不带 thead 的表格本地看着没问题直到业务方提需求“打印出来的第二页也要有表头”才发现结构层面压根没有表头区可以复用。这时候改起来就不是加个 CSS 能解决的得回头调整整段标记。还有个反向的坑把 thead 写在 tbody 后面。有人觉得浏览器会自动归位实际上不会。解析器在“表格主体”状态下遇到 thead 开始标签只是关闭当前行组然后按表格模式重新处理最终 DOM 顺序就是你的书写顺序thead 老老实实待在 tbody 后面。视觉上看着可能还行但打印重复、粘性表头、脚本按位置取值全都会错乱。2.2 th 的隐式行为默认样式和 scope 的自动推断th 这边也有隐式行为但性质不同。浏览器 UA 样式表里 th 的默认规则大概是display: table-cell; font-weight: bold; text-align: center; vertical-align: inherit;。这就是为什么你不写任何 CSS表头也是粗体居中。很多人靠这行默认样式偷懒觉得反正 th 天然就是表头样子。我建议反过来做显式把 th 的样式重置掉然后按设计稿重新写。原因很实际——加粗居中在移动端窄表格里经常挤爆而如果样式来自浏览器默认值你在排查“为什么这一列字这么粗”的时候会多绕一圈。另一个隐式行为是 scope 的自动推断。规范里说如果一个 th 没有显式写 scopeUA 可以自行推断它是行头还是列头。推断逻辑大致是看它在 thead 里还是 tbody 里。听起来很智能但实际表现因浏览器和屏幕阅读器而异。我的做法是一律显式声明 scope不赌推断——成本就几个字符收益是行为可预期。2.3 用开发者工具验证真实结构的三步走光看源码不算数得看解析后的 DOM。我的固定动作是这样第一步在 Elements 面板里折叠展开 table 节点确认层级是 table thead tr th。如果看到 tbody 直接挂在 table 下、里面还有 th说明表头没分区。第二步在 Console 里跑一句document.querySelector(table).tHead。返回 null 就是没有 thead返回元素就对了。再看table.tHead.rows.length多级表头这里应该是大于 1 的数。第三步切到 Accessibility 面板或者用浏览器的无障碍树查看器看这行表头有没有被识别成 columnheader 角色。如果 th 写成了 td 加粗这里会显示 cell语义直接就丢了。注意Accessibility 面板里角色是 columnheader 还是 rowheader取决于 scope 的取值。scopecol 对应 columnheaderscoperow 对应 rowheader不写的话可能是 generic 或按上下文推断。3. thead 的四个实战价值打印分页、粘性表头、列宽控制、脚本遍历3.1 打印分页时自动重复表头这是最被低估的一条后台系统里导出打印的需求特别多对账单、排班表、库存清单动辄几十上百行。用户在浏览器里按 CtrlP如果表格跨页第二页没有表头就完全看不懂哪一列是什么。这时候 thead 就是唯一的解法。打印引擎在分页时会把 thead 的内容重复到每一页顶部这是浏览器打印模块对表格行组的内置处理不需要你写任何 JS。但前提条件很明确表头必须包在 thead 里且必须是 tr th 的正常结构。我用过的几个主流桌面浏览器在这块表现一致只要是标准结构就能重复。反过来如果你是用 div 拼的“表格”或者 thead 里塞了 div 包裹层破坏了行组结构打印重复就失效了。我踩过一次为了让表头有个渐变背景我在 thead 外面套了一层 div结果打印出来只有第一页有表头。排查了半天才定位到这个包裹层——它让 thead 不再是 table 的直接子元素行组语义断了。配套的还有media print里的一些细节处理。比如表头里的排序按钮、筛选下拉打印时应当隐藏表头的固定定位要取消否则会遮挡内容。我一般这么写一段media print { thead th .sort-btn, thead th .filter-trigger { display: none; } thead th { position: static !important; background: #fff !important; } }3.2 粘性表头的正确落点其实在 th 上不在 thead 上长表格滚动时表头吸顶这个需求几乎每个后台都有。网上教程一大把但有一半是错的——直接给 thead 写position: sticky; top: 0。这么写在多数浏览器里完全不生效因为 thead 的默认 display 是 table-header-group不是普通的块级或表格行sticky 定位在这种显示类型上没有可靠的定位盒子。正确的做法是把 sticky 挂到 th 上.table-wrap { max-height: 480px; overflow: auto; } .table-wrap thead th { position: sticky; top: 0; z-index: 2; background: #fff; }这里有几个必须注意的点都是实测出来的一是背景色必须给。sticky 的 th 如果不设背景滚动时下面的内容会从字缝里透出来视觉上一塌糊涂。半透明背景也不行一样会透。二是border-collapse: collapse下边框会消失。这是经典问题表格为了线条好看通常设成 collapse但 sticky 元素的边框在这种模式下不跟着滚滚起来边框会“掉”在原地。解决办法是用box-shadow: inset 0 -1px 0 #e5e5e5模拟下边框或者改用border-collapse: separate; border-spacing: 0加单元格各自的边框。三是多级表头要分别算 top 值。两行表头的情况下第一行 th 设top: 0第二行 th 得设成第一行的高度比如top: 44px。这需要在渲染后测量或者用固定的行高。我用固定行高加 CSS 变量的方式搞定可维护性最好:root { --th-h: 44px; } thead tr:nth-child(1) th { top: 0; height: var(--th-h); } thead tr:nth-child(2) th { top: var(--th-h); }四是横向滚动时表头跟着走。如果表格比容器宽需要横向滚动第一列固定、表头固定同时存在时左上角那个格子要设left: 0加更高的 z-index否则两层会打架。3.3 table-layout: fixed 下列宽由 thead 那一行说了算这个点知道的人不多但对列表页体验影响很大。表格设了table-layout: fixed之后列宽不再由内容撑开而是由第一行的单元格宽度决定。而第一行通常就是 thead 里的那一行。也就是说thead 里的 th 实际上承担了“定义整张表列宽骨架”的职责。想让某一列宽一点改 thead 里对应 th 的宽度就行如果这列在 thead 里没写宽度浏览器会均分剩余空间。我一般这么组织列宽定义table { table-layout: fixed; width: 100%; } thead th:nth-child(1) { width: 56px; } /* 序号 */ thead th:nth-child(2) { width: 180px; } /* 名称 */ thead th:nth-child(3) { width: auto; } /* 描述吃掉剩余 */ thead th:nth-child(4) { width: 120px; } /* 时间 */ thead th:nth-child(5) { width: 96px; } /* 操作 */这套写法的好处是可预期。数据区里内容再长也不会把布局撑歪超出的部分配text-overflow: ellipsis加white-space: nowrap处理掉。顺便提一个反例如果你的表格是“没有 thead、第一行 tr 里全是 td”的结构fixed 布局会以那一行为准你改宽度得改 td维护起来很别扭而且语义上完全说不清那是表头。3.4 脚本遍历与数据导出tBodies 和 tHead 的分工写导出 Excel、打印、批量选择这类功能时thead 的边界价值就体现出来了。table.tBodies返回的是所有 tbody 的集合table.tHead返回表头。你拿到了明确的分区取值逻辑就干净const table document.querySelector(#data-table); const headers Array.from(table.tHead.rows[0].cells).map(th th.textContent.trim()); const rows Array.from(table.tBodies).flatMap(tbody Array.from(tbody.rows).map(tr Array.from(tr.cells).map(td td.textContent.trim()) ) ); console.log(headers, rows); // headers 与 rows 的列一一对应如果表格没有 theadtable.tHead就是 null你得回头从table.rows[0]里猜哪一行是表头逻辑立刻变脏。我在一个老项目里就遇到过表格结构是纯 tr 平铺导出时判断表头靠“第一行 th 的数量是否等于列数”碰到空表或者只有一行表头的情况各种边界出错最后重写成了标准 thead tbody 才收工。4. th 的正确打开方式scope、headers、abbr 与无障碍细节4.1 scope 这两个值怎么选以及不该混用的场景scope是 th 上最重要的属性它告诉辅助技术“这个表头管哪些格子”。取值有四个col、row、colgroup、rowgroup。日常九成场景只用前两个。判断方法很简单看这个表头是横向管一列还是纵向管一行。列标题写scopecol行标题写scoperow。colgroup和rowgroup用在表头本身跨组的情况比如一个表头通过 colspan 横跨了多列那个表头就应该标scopecolgroup。table thead tr th scopecol模块/th th scopecolgroup colspan2本月数据/th /tr tr th scopecol—/th th scopecol访问量/th th scopecol转化率/th /tr /thead tbody tr th scoperow渠道 A/th td12,480/td td3.2%/td /tr tr th scoperow渠道 B/th td8,905/td td2.7%/td /tr /tbody /table注意上面第二行表头里那个—它是占位单元格。这种写法在两级表头里很常见因为第一列被上面的“模块”占了第二行第一格其实没有新表头。有人会写空的 th或者干脆省略不写导致列错位我的做法是照常写 th 放个占位符样式上用伪元素隐藏或者留白保证列对齐不出错。提示scope 和 headers 属性不要在同一张表里混用。两套机制并存时不同辅助技术的解读方式不一致容易读出重复或错乱的表头信息。简单表用 scope复杂到无法用 scope 表达时才上 headers。4.2 headers 属性只有极复杂表头才值得动用的重武器当一个数据单元格的表头关系无法用行列顺序表达时比如一个 td 同时受横跨两组的表头影响且中间有合并单元格就得用headers属性值是若干个 th 的 id空格分隔。table thead tr th idh-name scopecol项目/th th idh-q1 scopecol第一季度/th th idh-q2 scopecol第二季度/th /tr /thead tbody tr th idh-a scoperow项目 A/th td headersh-a h-q11,200/td td headersh-a h-q21,540/td /tr /tbody /table说实话这个属性在真实项目里的使用率极低因为绝大多数业务的表头两三层就到顶了scope 完全够用而 headers 维护成本高得离谱——一旦列有增删所有 id 引用都要跟着改漏一个就出错。我个人的原则是能用 scope 表达清楚就绝不上 headers只有当表格存在“斜向表头”“双向交叉表”这类结构时才考虑并且尽量用脚本生成 id 和引用避免手写。值得一提的是部分老版本辅助软件对 headers 的支持也不一致有的会忽略有的会把 id 当成可见文本念出来。所以更稳妥的策略其实是把表格拆简单遇到真要复杂表头的情况考虑用多张小表或分栏布局替代。4.3 abbr 属性和其他细节知道它存在但别过度依赖abbr属性的设计初衷是给 th 提供一个缩写版本当表头文字太长、屏幕上放不下时可以显示缩写。规范里说某些 UA 在需要复述表头时可以用 abbr 代替完整内容。现实情况是现代浏览器对它的处理非常有限主要还是靠 CSS 的text-overflow: ellipsis解决显示问题所以别指望写个 abbr 就能自动缩略。我给它的定位是“锦上添花的语义补充”可以写但视觉问题还是得用样式解决。另外两个小细节一是 th 里可以放交互元素排序按钮、筛选图标、列宽拖拽手柄都可以放在 th 内这在数据表格组件里是标准做法但记得给按钮加aria-label说明用途别只放个图标。二是 th 的单元格对齐不要靠text-align硬改表格列的对齐最好统一在 colgroup 或者列级别的类上定义避免一列里 th 居左、td 居右这种视觉割裂。4.4 什么时候不该用 th三个明确的边界第一个边界视觉上加粗的普通单元格不该用 th。有些设计稿会把某几列数字加粗强调如果你为了省事直接改成 th屏幕阅读器会把这些数值念成“表头”对使用者是严重的误导。视觉样式和语义必须分开加粗用 fontWeight 解决。第二个边界不要用 th 包整行做“分组标题行”。我见过这种写法——一个 tr 里只放一个 th 加 colspan 等于总列数内容写“2024 年数据”。这种行在语义上是分组标题不是表头单元格。更合适的做法是在 tbody 里用 tr td 加scopecolgroup的 th 配合或者干脆拆成两张表各带自己的 thead。用 th 强行包整行会让辅助技术把整行的所有数据都关联到这个“表头”上读起来乱七八糟。第三个边界布局用途的表格不要用这些标签。用表格做页面布局是老黄历了现在还有人这么干配上一堆 th 纯粹增加噪音。布局用 flex 或 grid语义表格留给真正的数据。5. 常见错误与排查实录十个坑和我踩过的那些5.1 高频错误速查表下面这些是我在代码评审里反复见到的写法按出现频率排序。左边是错法右边是后果和改法错误写法直接后果正确做法tabletrtd表头/td...无表头分区打印不重复语义丢失补 thead 包住表头行单元格改 ththeadtd.../td/thead结构非法解析可能异常thead 内必须是 tr单元格用 ththeaddiv.../div/thead行组被破坏打印重复失效包裹层移到 table 外层th 包住整行做分组标题辅助技术关联错误拆表或用标准分组行表头全用 td class 加粗无障碍角色变成普通 cell改回 th样式单独控制thead 写在 tbody 后面DOM 顺序错乱脚本取值出错严格按 caption/colgroup/thead/tbody/tfoot 顺序给 thead 设 sticky多数浏览器不生效sticky 挂在 th 上sticky th 没设背景内容透出视觉混乱加不透明背景色collapse 模式下 sticky 边框消失滚动时边框留在原地用 inset box-shadow 模拟一表多个 thead规范不允行为不确定合并成一个 thead内部多行 tr5.2 排查思路从视觉异常反推结构问题排查表格问题我习惯按“先结构、后样式、再脚本”的顺序走效率最高。看到打印只第一页有表头先查结构table.tHead是不是 nullthead 是不是 table 的直接子元素。这两条中一条不满足就直接定位了。看到吸顶不生效先查元素用开发者工具选中那个 th看 Computed 面板里 position 是不是 sticky、top 有没有生效、父级有没有overflow: hidden把滚动容器截断了。sticky 失效最常见的原因其实是祖先元素设了 overflow 但又没形成真正的滚动容器导致 sticky 没有可滚动的参照。看到表头文字被截断或者列宽跳来跳去先查 table-layout如果是 auto内容会参与列宽计算长内容一进来表头就被挤改成 fixed 之后列宽由 thead 那一行决定问题自然消失。看到屏幕阅读器读出来的表头对不上先查 scope到底是 col 还是 row有没有漏写有没有和 headers 混用。我遇到过一次行标题写成了scopecol因为是从别处复制过来的结果整张表的播报全乱改一个单词就好了。5.3 几个只有实际做项目才会知道的细节**细节一空表的表头要保住。**列表页加载中、无数据时很多人习惯把整个表格藏起来显示空状态图。但用户如果此时切换列排序或者看筛选条件就失去了参照。我的做法是保留 thead只把 tbody 换成一行跨列的“暂无数据”提示。这样表头始终在交互也稳定。**细节二th 里放可排序按钮点击区域要给够。**把整个 th 做成点击排序是很自然的想法但如果 th 里还有筛选图标两个动作会打架。我的方案是 th 本身不绑事件内部放两个独立的按钮元素各自有清晰的点击区域和 aria-label。这样键盘操作也顺Tab 能依次走到。**细节三移动端表格转卡片时th 的价值反而更大。**小屏上表格通常会变成卡片列表每张卡片里“标签 值”成对出现。这时候原来的列标题在卡片里没法自动出现但如果你在 HTML 里给每个 td 加了>