table标签核心用途是语义化组织二维结构化数据，而非页面布局；它通过thead、tbody、th、caption等元素明确行列关系，保障可访问性、SEO及原生语义行为。
table 标签的核心用途是语义化地组织二维结构化数据，不是做页面布局的。它让浏览器、屏幕阅读器和搜索引擎能准确识别“这是表格”，而不是一堆 div 堆出来的假表格。
为什么直接用 table 而不用 div + CSS Grid/Flex？
因为语义正确性直接影响可访问性和 SEO。比如屏幕阅读器遇到 <table> 会自动播报行列关系、当前单元格位置；而用 <code>div 模拟的“表格”必须手动加 role="grid" 和大量 ARIA 属性，稍有遗漏就导致读屏失败。
- 后台管理系统、财务报表、API 返回的 JSON 列表渲染等场景，天然就是行+列结构，
table是最直白、最健壮的选择 -
display: table等 CSS 模拟方式无法触发原生表格的语义行为（如th[scope]关联、caption说明、thead/tbody逻辑分组） - 移动端缩放时，原生
table的列宽计算更稳定；CSS Grid 在复杂合并单元格（colspan/rowspan）下容易错位
响应式表格最常见的三种落地方式
没有“银弹”，选哪种取决于数据优先级和用户操作习惯。
-
水平滚动容器：适合列数固定、每列都关键（如日志列表、数据库查询结果）。只需给
table外层套一个<div style="overflow-x: auto">，再加table { min-width: 600px }防止过窄压缩 -
垂直堆叠（card 模式）：适合移动端以行为中心的操作（如订单详情、用户资料）。用媒体查询把
tr改为display: block，每个td变成带标签的块级项，配合::before伪元素插入原th文本 -
列可见性控制：适合分析型表格（如 BI 报表），允许用户勾选显示/隐藏列。用 JS 切换
td和对应th的class="hidden"，再配td.hidden { display: none }。注意：不能只 hidetd，必须同步处理th，否则语义断裂
colspan 和 rowspan 在响应式中为什么容易出问题？
它们破坏了表格的行列正交结构，导致 CSS 媒体查询或 JS 动态重排时无法可靠推导单元格归属。比如一个 th colspan="3" 在小屏下被拆成三列时，原语义“该标题统管三列”就丢失了。
立即学习“前端免费学习笔记（深入）”；
- 尽量避免在需要响应式的表格里用
rowspan—— 它会让tbody行高不可预测，垂直堆叠时内容错位风险极高 - 如果必须合并，优先用
colspan，且只在thead中使用；tbody内尽量保持 1:1 行列映射 - 用
aria-colspan/aria-rowspan补充语义，但别依赖它替代结构优化
真正难的不是让表格“看起来能缩放”，而是确保缩放后仍能被键盘导航、被屏幕阅读器正确朗读、被爬虫理解数据关系。所有响应式技巧都要回退到这个前提上验证。
