必须使用和显式分组表头与数据行，正确设置的scope属性，严格按colspan/rowspan逻辑占位，并添加语义化——这是保障表格结构合理、可维护、可访问的关键。
直接用 <table> 标签搭出来的表格，只要嵌套关系正确，浏览器就能渲染——但“能显示”不等于“结构合理”或“可维护”。现代语义化和可访问性要求下，裸写 <code><table><tr><td> 已经不够用了。
<h3>必须用 <code><thead>、<code><tbody> 显式分组
<p>很多初学者只写 <code><table><tr><th> 就完事，结果遇到滚动固定表头、JS 动态增删行、CSS 隔行变色时出问题。原因在于：没有 <code><thead> 和 <code><tbody>，浏览器无法区分“哪些是标题”“哪些是数据”，JavaScript 也难精准操作。
<ul><li><code><thead> 必须包裹所有表头行（<code><tr> 中含 <code><th> 的部分），且只能出现一次
<li><code><tbody> 包裹全部数据行，可多个（比如分页加载时动态插入新 <code><tbody>）
<li>省略 <code><tbody> 浏览器会自动补上，但 CSS 选择器如 <code>tbody tr:nth-child(odd) 就会失效
<th> 放在 <code><tbody> 里——那是语义错误，屏幕阅读器会误读为数据
<h3><code><th> 的 <code>scope 属性不是可选，而是关键
单行表头没问题，但遇到多级表头（比如“一季度”下分“1月”“2月”“3月”）或首列是行标题时，仅靠位置推断关联性，对残障用户极不友好。这时候 scope 就是明确告诉辅助技术“这个表头管哪一片”。
-
scope="col"：该<th> 管整列（最常见，用于列标题） <li> <code>scope="row"：该<th> 管整行（用于首列的行标识，如“张三”“李四”） <li> <code>scope="colgroup"或scope="rowgroup"：配合<colgroup></colgroup>使用，适合大范围分组 - 不写
scope，某些读屏软件会反复询问“这个表头对应哪一列？”，打断操作流 -
colspan="3"表示这个单元格占据当前行中连续 3 列的位置，后面那行就少写 2 个<td>（因为已被占用） <li> <code>rowspan="2"表示它向下跨 1 行（即占两行高度），那么下一行的对应列位置必须留空，不能塞<td> <li>用浏览器开发者工具检查 <code>Elements面板，看实际渲染出的列数是否与预期一致，比肉眼判断可靠得多 - 过度使用合并会让表格结构脆弱，尤其配合 JS 动态更新时容易崩——优先考虑拆分成多个简单表格
- 放在
<table> 开始后、<code><thead> 之前，且只能有一个 <li>内容要具体，例如 <code><caption>2025 年 Q2 各部门销售额（单位：万元）</caption>，而不是<caption>销售数据</caption> - CSS 可用
caption-side: bottom把它挪到底部，但语义位置不变 - 没
<caption></caption>的表格，在自动化可访问性检测（如 axe 浏览器插件）里直接标为“严重问题”
合并单元格时，colspan 和 rowspan 的值必须真实“腾出”空间
很多人写 <td colspan="3">汇总</td> 后，还在同一行里跟了两个 <td>，结果渲染错乱、列数对不上。本质是：<code>colspan 和 rowspan 不是“视觉拉伸”，而是“逻辑占位”。
<caption></caption> 不是装饰，是表格的“身份证”
搜索引擎和读屏软件都依赖 <caption></caption> 理解表格用途。把它当作文档标题来写，而不是加个“表格1”糊弄过去。
真正麻烦的从来不是写对标签，而是让每个标签承担它该有的语义责任——尤其是当表格要被 JS 操作、被 CSS 定制、被屏幕阅读器朗读，或者被爬虫收录时，漏掉一个 <thead> 或写错一个 <code>scope，都会在某个环节突然卡住。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
