auto-fill 会创建并保留空轨道，参与 gap 计算、影响可访问性和布局；auto-fit 则只生成所需轨道，移除空轨道，使子项真正撑满容器。
auto-fill 会保留空轨道，影响 gap 计算和 tab 键序
浏览器用 auto-fill 时，先按 minmax() 的最小值和容器宽度“硬算”最多能建几列，不管有没有子元素。比如 grid-template-columns: repeat(auto-fill, minmax(280px, 1fr)) 在 900px 容器中会生成 3 列（900 ÷ 280 ≈ 3.2 → 向下取整为 3），哪怕只放了 1 个卡片，剩下 2 条空轨道依然真实存在。
这些空轨道会参与 gap 计算（3 列产生 2 个 gap）、影响屏幕阅读器遍历顺序、甚至触发横向滚动——因为它们占位且分走 1fr 空间，把有内容的项挤窄了。
常见错误现象包括：
- 右侧明显留白，缩放时突然出现横向滚动条
- 用
nth-child(2)写样式却没生效——实际第二列是空轨道 - DevTools Grid 面板里显示的列线数量远多于可见卡片数
auto-fit 只建够用的轨道，空轨道被彻底移除
auto-fit 的行为逻辑完全不同：它先看有多少个子元素，只建刚好容纳它们的轨道数，再把空轨道原本占的空间均分给现有列。这意味着没有隐形占位列，也不参与 gap 分配。
立即学习“前端免费学习笔记（深入）”；
例如同样在 900px 容器中放 2 个卡片，auto-fit 就只建 2 条轨道，每条约 450px 宽（扣除 1 个 gap 后）；而 auto-fill 会建 3 条，每条被迫压缩到约 280px 左右（还要分摊 2 个 gap）。
适合场景：
- 卡片列表、图片画廊等内容数量不固定的响应式布局
- 需要子项真正“撑满容器”的视觉效果
- 避免因空轨道导致的布局抖动或可访问性问题
gap 会影响列数临界点，必须显式参与计算
很多人写 grid-template-columns: repeat(auto-fit, minmax(280px, 1fr)); gap: 1rem;，结果在 840px 宽度下只出 2 列而非预期的 3 列——问题不在 auto-fit，而在浏览器算“最多能塞几列”时，是拿容器宽减去所有 gap 占位后，再除以 minmax() 的最小值。
实际可用宽度 = 容器宽 − (列数 − 1) × gap，所以 gap: 1rem 会让临界点左移约 16px（2 列时扣 1 个 gap，3 列时扣 2 个）。调试时别只盯视觉，要打开 DevTools Grid 面板，勾选 “Show track sizes”，观察列线数量是否在缩放中跳变。
稳妥解法有两种：
- 把
gap算进最小值：minmax(calc(280px + 1rem), 1fr)，再保留gap: 1rem - 改用
minmax(max-content, 1fr)，让列宽随内容自然伸缩，避开像素临界点
子项尺寸约束不当会让 auto-fit 失效
auto-fit 不是万能的。如果子项内部有未约束的图片、flex 容器或固定宽元素，单格实际宽度可能远超 minmax() 设定的最小值，导致容器塞不下第二列——看起来就像“永远只显示一列”。
典型表现：
- 卡片内嵌一张未设
max-width: 100%的图片，把整列撑宽 - 子项用了
display: flex但没设flex-wrap: wrap或min-width - 子项设置了
width: 300px这类固定宽，覆盖了1fr分配
本质不是 auto-fit 失效，而是它按你写的 minmax(280px, 1fr) 去算列数，但子项自己突破了这个上限。检查子项的最终渲染宽度，比看 CSS 规则更直接。
真正容易被忽略的是：空轨道是否参与布局，不是靠“有没有内容”判断，而是由浏览器在 layout 阶段根据轨道生成逻辑决定的。一旦写错 minmax() 或漏算 gap，auto-fit 和 auto-fill 的行为差异就会从“视觉区别”变成“功能故障”。
