auto-fit必须搭配minmax()才有效，单独写repeat(auto-fit, 1fr)或repeat(auto-fit, 200px)无法实现自适应列数；minmax()定义弹性区间（如minmax(280px, 1fr)），auto-fit据此试算可容纳列数并合并空轨道，使有内容的列均分剩余空间。
auto-fit 必须和 minmax() 搭配才有效
单独写 repeat(auto-fit, 1fr) 或 repeat(auto-fit, 200px) 不会自适应列数，浏览器只会按固定规则分列或压缩到不可读。真正起作用的是 minmax() 定义的“弹性区间”：它告诉浏览器“这列至少要多宽、最多能占多少空间”。auto-fit 的任务是基于这个区间反复试算——能塞几列就塞几列，塞不下就合并空轨道。
常见错误现象：
• 小屏下卡片被压成窄条（用了 minmax(100px, 1fr)，最小值太小）
• 列数死在 3 列不动（最小值设成 minmax(300px, 1fr)，而容器宽度始终 ≥ 900px）
• 看起来没响应（子项写了 width: 300px，直接覆盖网格计算）
-
minmax(280px, 1fr)是卡片类布局较稳的起点：保证文字不换行挤压，大屏又能均分剩余空间 - 最小值禁用
em/rem：字体缩放会改变列数，优先用px或clamp(240px, 25vw, 320px) - 别把
1fr换成auto或max-content：前者失去弹性约束，后者让列宽随内容暴胀，auto-fit直接失效
auto-fit 和 auto-fill 的行为差异直接影响布局是否干净
auto-fit 会把没内容的列轨道合并掉，只保留有子项的列，并把省下的空间均分给它们；auto-fill 则不管有没有内容，只要空间够就铺满所有可能的轨道。这意味着：
- 卡片列表、导航栏、产品网格等“内容驱动”场景，一律用
auto-fit：避免小屏右侧大片空白，也防止子项少时列数虚高 - 仪表盘、日历、拖拽占位区等“结构先行”场景，才考虑
auto-fill：需要预留槽位，哪怕当前为空 - 用
auto-fill却没内容时，DevTools Layout 面板里能看到一排灰色空轨道线；auto-fit下这些线直接消失
gap 和子项样式会悄悄破坏 auto-fit 计算
gap 算进容器可用宽度里。如果设了 gap: 2rem，而容器宽仅 600px，实际可分配给列的宽度可能只剩 540px 左右——这时 minmax(280px, 1fr) 就只能塞下 1 列，不是代码错了，是 gap 挤占了空间。
立即学习“前端免费学习笔记（深入）”；
- 子项加了
width、float、position: absolute或display: inline-block，都会让网格项脱离文档流，auto-fit失去计算依据 - 长文本没处理（比如没设
word-break: break-word），可能撑破单列宽度，导致整行重排甚至横向溢出 - 用
gap而不是margin控制间距：前者是 Grid 原生机制，不会干扰轨道计算；后者容易在边缘多出半倍间距，还得额外写负边距修正
旧版 Safari 和安卓 WebView 需要兼容性兜底
iOS 15.4 之前、部分安卓 WebView 对 auto-fit 支持不全，表现为列数不变化或布局错位。不能靠猜，得用 @supports 显式检测：
grid-template-columns: repeat(3, 1fr);
@supports (grid-template-columns: repeat(auto-fit, minmax(0, 1fr)))) {
grid-template-columns: repeat(auto-fit, minmax(280px, 1fr)));
}
更关键的是：别指望 auto-fit 在所有环境下都表现一致。小屏测试必须真机跑，尤其注意 iOS 16.4 以下版本和某些定制安卓系统里的 WebView 行为。
真正难的不是写出那行 repeat(auto-fit, minmax())，而是理解它每一步怎么算——否则改来改去还是“看着动、实际卡死”。
