HTML5中禁止用<table>做页面布局，因其语义错误、可访问性差、响应式困难；应使用Flexbox（一维）或Grid（二维）替代，仅真实表格数据才适用<table>。
别用 <table> 做页面布局——这不是建议，是规范强制要求。它会导致屏幕阅读器误读、SEO 解析错乱、响应式断层，且现代 CSS 已完全能覆盖所有旧场景。
为什么 <table> 布局在 HTML5 中直接报错
W3C 和 WCAG 明确将 table-used-for-layout 列为可访问性错误。浏览器不会阻止渲染，但辅助工具会把导航栏读成“第一行：首页、关于、联系”，而跳过语义层级；搜索引擎也可能把页脚当成数据表 footer 行来索引。
-
<table>的语义就是「二维结构化数据」，不是「页面骨架」 - 写
cellspacing="0"或border="0"无法掩盖语义污染，HTML5 已废弃这些属性，只留 CSS 控制 - 媒体查询对
display: table-cell支持极差，比如@media (max-width: 768px)下很难让两栏变单栏，flex 或 grid 一行flex-direction: column就搞定
Flexbox 替代两栏/三栏表格布局的实操要点
90% 的旧式 <table> 页面结构（如 header + sidebar + main + footer）用 Flexbox 更轻量、更可控，且 IE11 仍可安全使用。
- 父容器设
display: flex，子元素默认水平排列；垂直居中加align-items: center，顶部对齐用align-items: flex-start - 侧边栏固定宽、主内容自适应：给侧边栏设
width: 240px，主内容设flex: 1（不是flex: auto，后者不收缩） - 避免
flex-wrap: wrap误用：它只在空间不足时换行，若想强制单行，加flex-shrink: 0防压缩 - 注意源码顺序与视觉顺序分离：Flexbox 允许用
order调整渲染序，但别滥用——屏幕阅读器仍按 DOM 顺序读，order只影响视觉
CSS Grid 替代复杂嵌套表格的边界条件
Grid 不是万能锤。它适合真正二维结构（如后台仪表盘、卡片网格、多区域响应式布局），但别用它排一行按钮或简单导航——那属于 Flexbox 的舒适区。
立即学习“前端免费学习笔记（深入）”；
- 用
grid-template-areas命名区域比硬写行列更直观，例如："header header" "nav main" "footer footer"，后续只需改一行就能切换移动端布局 -
grid-auto-flow: dense有风险：它会让小格子自动填空，可能打乱你预设的区域顺序，调试时先关掉 - IE11 不支持原生 Grid（仅支持旧版 -ms-grid），如需兼容，要么降级用 Flexbox，要么用 Autoprefixer + postcss-grid-kiss 等工具补全，但成本远高于放弃 IE
- 打印样式易被忽略：Grid 布局在
@media print下可能错位，建议加@supports (display: grid)条件包裹，否则 fallback 到 block 流
什么情况下还必须用 <table>？
只有当内容天然具备行列关系、且每个单元格值可被独立引用时，<table> 才是唯一正确选择——比如财务报表、课程表、API 返回的 JSON 数据表格化展示。
- 必须写
<thead>和<tbody>：否则position: sticky表头失效，屏幕阅读器无法关联列头与数据 -
colspan/rowspan不要混用超过两层：三层以上极易导致隐式网格错位，浏览器补空单元格后视觉崩塌，此时应考虑拆成多个独立表格或改用 Grid 模拟 - 禁用
display: table做等高布局：它触发表格渲染引擎，首屏性能下降明显，Flexbox 的align-items: stretch或 Grid 的默认行为更高效
最容易被忽略的点是：语义错误不会立刻报错，但会在导出 PDF、语音朗读、搜索引擎抓取时批量暴露。与其后期修复，不如从第一个 <div class="wrapper"> 就选对方向。
