table-layout: fixed 是表格自适应的必要前提，需配合 width: 100% 生效，可避免小屏下列宽崩坏；列多时宜改用 data-label 堆叠卡片，不可删减字段则需优化滚动容器体验。
直接设 width: 100% 不足以让表格“真正自适应”——它大概率会在小屏上文字挤压、列宽崩坏或横向溢出，根本原因是浏览器默认用 table-layout: auto 动态计算列宽，而窄屏需要的是可控的渲染逻辑和信息优先的交互方式。
为什么 table-layout: fixed 是必须的第一步
默认的 table-layout: auto 会等所有内容加载完才确定列宽，小屏下一行里一个长邮箱或 UUID 就能把整列撑开，拖垮整表。改成 table-layout: fixed 后，列宽由第一行 <th> 或显式 <code><col> 的 width 决定，渲染快、可预测、不随内容抖动。
但注意：table-layout: fixed 必须搭配 width: 100% 才生效；否则浏览器仍按内容宽度渲染。IE8+ 支持，但 Outlook（基于 Word 渲染引擎）完全不认这个属性，邮件中禁用。
-
<th style="width: 25%">姓名</th>比<th width="25%"> 更可靠（HTML <code>width属性在现代 CSS 中已弱化） - 如果列数多且难均分，别硬凑百分比，改用
minmax(120px, 1fr)+ CSS Grid 替代方案更稳 - 没设任何列宽时，
fixed会让未指定列平分剩余空间，容易导致关键列过窄 - 必须隐藏
<thead>，否则堆叠后表头重复出现 <li>避免用 <code>float或inline-block实现堆叠——窄屏下易换行错位，block最稳 - 不要依赖 JS 注入
data-label，静态写死更可靠，也利于 SSR 和 SEO - 容器
width: 100%+overflow-x: auto，<table> 自身不设 <code>width，靠内容撑开 - 别给
<table> 设 <code>min-width，否则小屏下强制拉宽容器，破坏滚动意图 - 滚动条样式要测试真机，CSS 伪元素（如
::-webkit-scrollbar）仅限 WebKit，Firefox 需另配
移动端列太多时，别硬撑——用 data-label 堆叠代替横向滚动
当列数 ≥ 4，或字段语义强（如“订单号”“创建时间”“操作人”），横向滚动体验差，用户要反复滑动、找不准上下文。此时应放弃表格结构视觉，转为块级卡片堆叠，每条记录自包含语义。
立即学习“前端免费学习笔记（深入）”；
核心是给每个 <td> 加 <code>data-label 属性：<td data-label="状态">已发货</td>，再用 CSS 在小屏下把 <tr> 设为 <code>display: block，<td> 设为 <code>display: block 并用 ::before { content: attr(data-label) } 插入表头。
报表类表格必须横向滚动？容器设置比样式更重要
后台数据列表、财务明细这类字段不可删减的场景，横向滚动是务实选择，但卡顿、无提示、手势冲突才是真实痛点。
关键不是加个 overflow-x: auto 就完事，而是滚动容器本身要干净：只包一层 <table>，不嵌套多个 <code>.table-responsive；iOS Safari 在滚动中点击 <input> 或 <select></select> 易失焦，需加 touch-action: manipulation；Firefox/Edge 默认滚动条不可见，得显式加 scrollbar-width: thin 或用伪元素定制。
最常被忽略的一点：没有银弹方案
列少、语义弱（如“编号｜名称｜操作”）→ 用 table-layout: fixed + 百分比列宽；列多、字段不可删 → 滚动容器；字段语义强、操作频繁 → 堆叠卡片。选哪种，取决于用户在什么设备上看什么数据、要做什么操作，而不是“哪个方案更高级”。上线前必须在真机上验证 table-layout 行为，尤其是含表单控件的单元格在 iOS 上的点击响应。
