直接给 加 overflow-x: auto 无效，因其是格式化上下文边界；需外层 div 设 max-width、表格设 display: block 和 min-width: max-content，单元格加 white-space: nowrap，固定列用 position: sticky 时须同步作用于 th 和对应 td 并设 z-index 和背景色。
直接给 <table> 加 <code>overflow-x: auto 不会触发横向滚动——表格默认撑满内容宽度，根本不会溢出父容器。固定列用 position: sticky 在原生表格里大概率静默失效，不是写法错，是浏览器渲染机制不支持。
为什么 overflow-x: auto 对 table 没反应
根本原因是 <table> 是「格式化上下文边界」，其内部宽度计算独立于父容器，<code>overflow 无法截断它。必须让表格脱离表格布局流，才能被父容器约束。
- 外层
<div> 必须设 <code>max-width（不能只靠width: 100%），否则在弹性布局中尺寸不可控 <table> 要加 <code>display: block和min-width: max-content，强制它按内容总宽计算最小尺寸- 所有
<th> 和 <code><td> 建议加 <code>white-space: nowrap（尤其移动端），防止换行干扰宽度判断 - 避免对单元格设固定
width总和超限——这会导致内容溢出但外部无滚动条 - 仅给
<th> 加 <code>position: sticky; left: 0不够，必须同步作用于对应列的所有<td> <li>必须确保 <code><table> 父容器有 <code>overflow-x: auto，且该父容器不能是display: table或inline元素 -
z-index必须显式设置（如z-index: 2），否则滚动时会被右侧列盖住 - 背景色（
background-color）不可省——没有它，固定列下会透出后面的内容 - 固定列加
position: sticky; left: 0; z-index: 2; background: white，非固定列保持默认流式布局 - 用
display: flex模拟时，确保父容器（.table-header/.table-body）总宽 > 外层容器宽度，靠flex: 0 0 200px控制列宽并禁止换行 - 若必须保留
<table> 语义（如无障碍或 SEO），可用伪元素 + JS 同步滚动偏移，但这是兜底方案，不是首选 <h3>移动端特别要注意的坑</h3> <p>iOS Safari 对 <code>overflow容器内的滚动行为限制更严，尤其当表格含大量单元格或用了position: sticky表头时，容易卡顿或拖不动。- 滚动容器必须加
-webkit-overflow-scrolling: touch（iOS 15+ 已弃用但仍有影响，建议保留） - 避免在
<td> 内使用 <code>flex布局或position: absolute——它们会干扰滚动区域检测 - 如果用了
position: sticky表头，确保其父<thead> **不要**设 <code>display: block，否则 sticky 失效；推荐直接作用于<th> 并配 <code>top: 0和background - 列宽对齐必须手动控制：给每列
<th> 和 <code><td> 设相同 <code>min-width或width，否则滚动后表头与内容错位真正卡住的从来不是 CSS 属性本身，而是表格渲染机制与现代布局需求之间的错位。固定列不是“加个 sticky 就完事”，而是要明确知道谁在提供滚动上下文、谁在响应定位、谁在控制宽度——漏掉任意一环，都会在某个机型或某个数据量下突然崩掉。
- 滚动容器必须加
position: sticky 在表格中为何常失效
sticky 要求定位元素的**最近块级祖先容器**提供滚动上下文，而 <tr> 默认是 <code>display: table-row，不是块级容器；<td> 是 <code>display: table-cell，会阻断定位传播。Chrome、Firefox、Safari 对该组合的支持长期不一致。
更稳的替代方案：用 grid 或 div 模拟表格
放弃原生 <table> 是解决兼容性和控制力问题最直接的方式。语义可弱化，但结构可控性大幅提升。
<ul>
<li>用 <code>display: grid 时，grid-template-columns 前几列需显式指定宽度（如 120px 1fr 1fr），不能全用 1fr，否则 left 偏移无法对齐
