绝大多数移动端卡片类布局应使用 auto-fit 而非 auto-fill；因其在小屏下能自动丢弃空轨道，将空间分配给有内容的列，避免塌陷占位、文字换行、触控失效等问题，配合 minmax(280px, 1fr) 和合理 gap 设置可兼顾 iPhone SE 与 iPad 的响应式表现。
绝大多数移动端卡片类布局该用 auto-fit，不是 auto-fill；但前提是子元素不硬撑、minmax() 下限设得准、gap 不吃掉太多可用宽度。
为什么 auto-fit 在小屏下更稳
移动端屏幕窄、卡片内容长度不一，auto-fit 会丢掉空轨道，把省下的空间分给有内容的列，避免出现“能放三列但只填了两张卡，第三列塌成 0 宽却仍占位”的情况。而 auto-fill 强行保留所有可能轨道，iPhone SE（375px）下常生成两列，每列只剩 ~160px，文字全换行、图标点不中、按钮被压扁。
-
auto-fit：2 张卡 → 渲染 2 列，每列 ≈ (375 − gap) ÷ 2，宽度可读可点 -
auto-fill：2 张卡 → 可能渲染 3 列，第 3 列宽度为 0，但 gap 仍算 2 次，视觉错位 + tab 键序异常 - DevTools 里勾选 “Show track sizes”，
auto-fit显示的列线数 = 实际子元素数；auto-fill显示的列线数 = 计算出的最大可能列数
minmax() 的 280px 是怎么来的
这不是设计稿随便写的数字，而是实测底线：含 padding、border、14px 字号、44px 触控高度后，文字还能单行、按钮可点击、图表坐标轴不裁切的最小安全宽度。
- 设成
minmax(200px, 1fr)：iPhone SE 下两列需 2×200 + gap ≈ 416px > 375px，被迫退单列，但卡片内文字频繁折行，行高失控 - 设成
minmax(350px, 1fr)：iPad 竖屏（768px）只能塞 2 列，浪费横向空间，920px 才上 3 列，过渡生硬 -
280px是平衡点：768px 下刚好 2 列（2×280 + 16 = 576），920px 左右自然上 3 列（3×280 + 32 = 872）
gap 和子元素不收敛是两大隐形杀手
gap 不是装饰，它直接参与列数计算：n 列产生 n−1 个 gap，这部分宽度从容器中扣除后再除以 minmax() 最小值。子元素若没设 max-width: 100% 或 min-width: 0，会顶破网格约束，让 auto-fit 彻底失效。
立即学习“前端免费学习笔记（深入）”；
- 错误写法：
grid-template-columns: repeat(auto-fit, minmax(280px, 1fr)); gap: 1rem;→ 实际可用宽度少约 16px，可能意外退为单列 - 稳妥解法：改用
minmax(calc(280px + 1rem), 1fr)，再保留gap: 1rem；或小屏改用gap: 12px - 图片没加
max-width: 100%; height: auto、文字块含white-space: nowrap、子项用了flex: 1却没加min-width: 0，都会导致列宽远超预期
兼容性和降级不能靠 JS 检测
auto-fit 无法在 Safari ≤15.4 或 iOS 14 及更早版本中稳定工作，且不报错，只是静默退化为单列。JS 检测 CSS 支持不可靠，必须用原生 fallback。
- 用
@supports (display: grid)包裹现代语法，外面写display: flex; flex-wrap: wrap降级 - 别用
repeat(3, 1fr)当 fallback——它在小屏下照样崩；真兜底用float或inline-block + calc()，保基本可读性即可 - 测试时先设
gap: 0确认列数是否符合预期，再逐步加回合理值；用outline: 1px solid red看父容器真实宽度，别信“看起来满了”
真正难处理的不是语法本身，而是当卡片数量动态变化（比如搜索过滤、分页加载）时，auto-fit 的列数跳变会引发视觉抖动；而 auto-fill 的隐形空列又容易在动画或屏幕阅读器遍历中暴露问题。这时候得靠 grid-auto-flow: dense 或显式 grid-column 控制，不能只依赖 repeat 行为。
