HTML5中仍用于语义化二维数据，禁用于布局；须用提升可访问性与打印支持；小屏用overflow-x:auto而非缩放；多级表头用scope或headers确保无障碍。
HTML5 里 <table> 还用不用？
<p>用，而且照旧是唯一语义化表达二维数据关系的标准方式。<a style="color:#f60; text-decoration:underline;" title="html" href="https://www.php.cn/zt/15763.html" target="_blank">html</a>5 没废弃 <code><table>，只是更强调“只用于表格数据”，别再拿它搞页面布局——那个时代真过去了。
<p>常见错误现象：<code>display: table 套嵌三层做响应式卡片，结果屏幕阅读器读成“表格含表格含表格”，用户摸不着头脑；或者用 <div> + CSS Grid 模拟表格，却漏掉 <code><th> 的 <code>scope 属性，导致残障用户无法关联表头和单元格。
- 真实表格数据（如成绩单、财务报表、API 返回字段对照）必须用
<table><li>纯视觉对齐需求（比如三栏介绍模块）改用 <code>flex 或 grid，别硬套 <tr><td>
<li>
<code><caption></caption> 是表格的可访问标题，不是装饰，别空着或写“表格1”
<thead><code><tbody><code><tfoot> 必须写全吗？
<p>不强制，但写了才有实际作用：滚动长表格时，<code><thead> 可配合 <code>position: sticky 固定表头；打印时浏览器可能自动重复 <thead> 到每页顶部；<code><tfoot> 会影响渲染顺序（它会出现在 <code><tbody> 前面，即使 HTML 里写在后面）。
<p>容易踩的坑：<code><tbody> 被 JS 动态删掉后，<code><tr> 直接挂在 <code><table> 下，此时 CSS 选择器 <code>tbody tr 就失效了；另外，某些老版本 Safari 对 <tfoot> 渲染错位。
<ul><li>哪怕只有一组表头，也显式包一层 <code><thead>，别裸写 <code><tr><th>
<li>动态生成表格时，检查是否意外移除了 <code><tbody> 容器
<li><code><tfoot> 实用场景少，除非真需要页脚汇总且要打印支持，否则先不加
<h3>怎么让表格在小屏上不横向滚动？</h3>
<p>靠 CSS 强制缩放或隐藏列都是下策。真正可行的是：用 <code>overflow-x: auto 包住表格，让容器自己滚动，而不是压扁字体或砍掉内容。
立即学习“前端免费学习笔记（深入）”；
性能影响：给 <table> 父容器设 <code>overflow-x: auto 是最轻量方案；用 JS 监听宽度动态切换为卡片堆叠模式（每行变一个 <section></section>）适合复杂交互，但增加维护成本。
- 父容器加
overflow-x: auto，表格本身不设 width: 100%（否则会拉伸列宽破坏可读性）
- 避免对
<td> 设 <code>white-space: nowrap，这会让文本撑破容器
- 移动端优先的话，用媒体查询把
<table> 换成语义等价的 <code><dl></dl> 结构（<dt></dt> 当字段名，<dd></dd> 当值），比“响应式表格插件”更可靠
aria-label 和 scope 属性到底填什么？
scope="col" 或 scope="row" 是给 <th> 用的，告诉辅助技术“这个表头管一列还是管一行”。<code>aria-label 是兜底方案——当视觉上合并了表头、无法用 scope 描述时才加，比如跨多列的总标题。
错误示范：<th aria-label="姓名">Name</th> —— 这纯属多余，屏幕阅读器本来就会读 “Name”；<td scope="col"> —— <code>scope 只能用于 <th>，放 <code><td> 上完全无效。
<ul><li>
<code><th scope="col">销售额</th> 表示这一列所有 <td> 都属于“销售额”维度
<li>多级表头时，用 <code>id + headers 属性关联（如 <td headers="q1 q2">）
<li>整个表格语义不清时，在 <code><table> 上加 <code>aria-label="2024年各区域季度销售明细"，比塞个看不见的 <caption></caption> 更直接
表格的复杂度往往藏在表头结构里，不是列数多就难，而是“哪一列归哪个分组”没说清，这时候再多的 CSS 都救不了可访问性。
<table><li>纯视觉对齐需求（比如三栏介绍模块）改用 <code>flex 或 grid，别硬套 <tr><td>
<li>
<code><caption></caption> 是表格的可访问标题，不是装饰，别空着或写“表格1”<thead><code><tbody><code><tfoot> 必须写全吗？
<p>不强制，但写了才有实际作用：滚动长表格时，<code><thead> 可配合 <code>position: sticky 固定表头；打印时浏览器可能自动重复 <thead> 到每页顶部；<code><tfoot> 会影响渲染顺序（它会出现在 <code><tbody> 前面，即使 HTML 里写在后面）。
<p>容易踩的坑：<code><tbody> 被 JS 动态删掉后，<code><tr> 直接挂在 <code><table> 下，此时 CSS 选择器 <code>tbody tr 就失效了；另外，某些老版本 Safari 对 <tfoot> 渲染错位。
<ul><li>哪怕只有一组表头，也显式包一层 <code><thead>，别裸写 <code><tr><th>
<li>动态生成表格时，检查是否意外移除了 <code><tbody> 容器
<li><code><tfoot> 实用场景少，除非真需要页脚汇总且要打印支持，否则先不加
<h3>怎么让表格在小屏上不横向滚动？</h3>
<p>靠 CSS 强制缩放或隐藏列都是下策。真正可行的是：用 <code>overflow-x: auto 包住表格，让容器自己滚动，而不是压扁字体或砍掉内容。
立即学习“前端免费学习笔记（深入）”；
性能影响：给 <table> 父容器设 <code>overflow-x: auto 是最轻量方案；用 JS 监听宽度动态切换为卡片堆叠模式（每行变一个 <section></section>）适合复杂交互，但增加维护成本。
- 父容器加
overflow-x: auto，表格本身不设width: 100%（否则会拉伸列宽破坏可读性） - 避免对
<td> 设 <code>white-space: nowrap，这会让文本撑破容器 - 移动端优先的话，用媒体查询把
<table> 换成语义等价的 <code><dl></dl>结构（<dt></dt>当字段名，<dd></dd>当值），比“响应式表格插件”更可靠aria-label 和 scope 属性到底填什么？
scope="col"或scope="row"是给<th> 用的，告诉辅助技术“这个表头管一列还是管一行”。<code>aria-label是兜底方案——当视觉上合并了表头、无法用scope描述时才加，比如跨多列的总标题。错误示范：
<th aria-label="姓名">Name</th>—— 这纯属多余，屏幕阅读器本来就会读 “Name”；<td scope="col"> —— <code>scope只能用于<th>，放 <code><td> 上完全无效。 <ul><li> <code><th scope="col">销售额</th>表示这一列所有<td> 都属于“销售额”维度 <li>多级表头时，用 <code>id+headers属性关联（如<td headers="q1 q2">） <li>整个表格语义不清时，在 <code><table> 上加 <code>aria-label="2024年各区域季度销售明细"，比塞个看不见的<caption></caption>更直接表格的复杂度往往藏在表头结构里，不是列数多就难，而是“哪一列归哪个分组”没说清，这时候再多的 CSS 都救不了可访问性。
