应仅在展示行列关系明确的二维结构化数据时使用 ，如课程表、财务报表；其他布局场景一律用 配合 css flex 或 grid。
什么时候该用 <table>，而不是 <code><div>
<p>只有当你在展示真正具有行列关系的二维结构化数据时，<code><table> 才是语义正确且无障碍友好的选择。比如课程表、财务报表、API 返回的字段对照表、带表头的统计结果等。
<p>常见错误现象：<code><table> 被用来做页眉+侧边栏+主内容+页脚的整页布局；或用多层嵌套 <code><tr><td> 实现卡片网格 —— 这类写法会让屏幕阅读器误读为“表格”，破坏可访问性，也增加 SEO 混淆风险。
<p>使用场景判断清单：</p>
<ul><li>是否每一行都有明确的列含义（如“姓名｜年龄｜城市”）？→ 是 → <code><table><li>是否需要原生支持 <code>colspan/rowspan 来合并逻辑单元？→ 是 → <table><li>是否依赖浏览器对表格的自动列宽计算（如内容撑开列宽）？→ 是 → 可考虑 <code><table>，但注意响应式退化
<li>是否要动态增删整行/整列，并保持结构稳定？→ 否 → <code><div> + <code>flex 或 grid 更易维护
<div> 布局必须配合 CSS 才能生效
<p><code><div> 本身不带任何布局能力，它只是一个无语义的容器。直接写一堆 <code><div> 不会自动排成一行或一列，也不会对齐、换行、等高 —— 这些全靠 CSS 驱动。
<p>容易踩的坑：</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill7761" title="Article To Html"><img
src="https://img.php.cn/upload/skill/000/000/081/179168408018805.jpg" alt="Article To Html" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill7761" title="Article To Html" class="overflowclass">Article To Html</a>
<p class="overflowclass">文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。</p>
</div>
<a rel="nofollow" href="/xiazai/skill7761" title="Article To Html" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
<ul>
<li>只写 <code><div class="row">
<div class="col">A</div>
<div class="col">B</div>
</div>，但没定义 CSS 的 display: flex 或 float → 页面仍垂直堆叠
<div> 布局必须配合 CSS 才能生效
<p><code><div> 本身不带任何布局能力，它只是一个无语义的容器。直接写一堆 <code><div> 不会自动排成一行或一列，也不会对齐、换行、等高 —— 这些全靠 CSS 驱动。
<p>容易踩的坑：</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill7761" title="Article To Html"><img
src="https://img.php.cn/upload/skill/000/000/081/179168408018805.jpg" alt="Article To Html" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill7761" title="Article To Html" class="overflowclass">Article To Html</a>
<p class="overflowclass">文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。</p>
</div>
<a rel="nofollow" href="/xiazai/skill7761" title="Article To Html" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
<ul>
<li>只写 <code><div class="row">
<div class="col">A</div>
<div class="col">B</div>
</div>，但没定义 CSS 的 display: flex 或 float → 页面仍垂直堆叠
float 后父容器高度塌陷，却没加 overflow: hidden 或 clear: both → 后续元素错位width: 100% + 固定 px 内边距，导致横向溢出 → 应改用 box-sizing: border-box
性能影响：现代浏览器对 flex 和 grid 的渲染优化已很成熟，但大量嵌套 <div>（尤其无 class 或 role）仍会拖慢 DOM 解析和可访问树构建。
<h3>响应式适配能力差异明显</h3>
<p><code><table> 在小屏上几乎无法优雅降级：列太多就横向滚动，隐藏列需 JS 控制，<code>th 与 td 的语义绑定让“把行转成卡片”变得困难。
<div> + <code>@media 或 grid-template-areas 可以做到：
- 桌面端三栏 → 平板端双栏 → 手机端单栏流式排列
- 同一组数据，在桌面显示为表格，在手机显示为折叠卡片（用
details+summary） - 通过
grid-auto-flow: dense动态填充空缺，适应不规则内容高度
关键提醒：不要为了“兼容老浏览器”而放弃 grid —— Chrome/Firefox/Safari/Edge 全系已原生支持多年；IE11 是唯一例外，但它的市场份额已低于 0.1%（2026 年数据），除非明确要求支持，否则无需降级。
加载行为与 DOM 渲染时机不同
<table> 渲染是“阻塞式”的：浏览器必须解析完整个 <code><table> 标签块（含所有 <code><tr>/<code><td>），才能确定列宽、对齐方式并开始绘制。网络中断或长列表会导致白屏延迟。
<p><code><div> 是“流式渲染”的：遇到一个 <code><div> 就立即布局并绘制，后续内容边下载边显示。这对首屏加载速度和用户感知至关重要。
<p>实际影响点：</p>
<ul><li>含 50 行数据的报表页，用 <code><table> 可能比 <code><div> + <code>grid 多出 300–800ms 的首屏时间（实测 Chrome DevTools Lighthouse）
<table> 无法分块 flush，而 <code><div> 可配合 streaming HTML 逐步输出
<li>如果页面顶部有大表格，且下方有重要 CTA 按钮，用户可能因表格未完成渲染而无法点击</li>
<p>最常被忽略的一点：语义污染不可逆。一旦用 <code><table> 做了布局，即使后期改成 <code><div>，旧链接、爬虫缓存、第三方分析脚本仍可能按表格结构解析 DOM —— 所以从第一行 HTML 就得选对标签。</div>
