auto-fit列数突然减少是因为其轨道生成逻辑先依据子元素数量和minmax()最小值计算可容纳列数，再均分容器宽度；当容器缩至临界点（受gap影响左移），可用宽度不足以支撑原列数，便向下取整跳变。
auto-fit 为什么列数会突然减少？
不是容器变窄了才“少一列”，而是 auto-fit 的轨道生成逻辑本身就不看容器上限，只看子元素数量和 minmax() 最小值能否塞下——它先数有几个子项，再决定建几条轨道，然后把整行宽度均分过去。
比如 minmax(280px, 1fr) 搭配 2 个卡片，在 850px 宽容器里就只建 2 条轨道，每条约 425px；窗口缩到 839px 时，可能连 2 条完整轨道都撑不满（839 ÷ 280 ≈ 2.99 → 向下取整为 2），但若再缩 1px 到 838px，计算结果变成 838 ÷ 280 ≈ 2.99 仍为 2 —— 真正的跳变点其实在临界值附近浮动，受 gap 影响更大。
-
gap会从容器宽里提前扣减：3 列有 2 个gap，实际可用宽度 = 容器宽 − 2 ×gap - 所以写
grid-template-columns: repeat(auto-fit, minmax(280px, 1fr)); gap: 1rem;时，临界点比预期左移约 32px - 调试时打开 DevTools 的 Grid 面板，勾选 “Show track sizes”，直接看列线数量是否在缩放中跳变
auto-fill 为什么右侧总有留白甚至横向滚动？
auto-fill 不关心你放了几个子元素，它只按 minmax() 最小值和容器宽度“硬算”最多能建几列。哪怕只有一个卡片，只要容器够宽，它就建满所有可能轨道。
例如 repeat(auto-fill, minmax(280px, 1fr)) 在 900px 容器中会生成 3 列（900 ÷ 280 ≈ 3.2 → 向下取整为 3），但只有 1 个卡片时，剩下 2 条空轨道依然真实存在、参与 1fr 分配，还计入 gap 计算——结果就是内容被挤压，右侧留白，严重时触发横向滚动。
立即学习“前端免费学习笔记（深入）”；
- 空轨道仍受
gap影响：设gap: 1rem，3 列就有 2 个 gap，总空白 = 2 × 1rem - 若用
1fr，空列也会均分剩余空间，导致有内容的项宽度异常缩小 - 想避免留白又必须用 auto-fill？把
gap算进最小值：minmax(calc(280px + 1rem), 1fr)，再保留gap: 1rem
为什么图片或 flex 子项会让 auto-fit 只显示一列？
不是语法错了，是 minmax() 的最小值被内容撑开了。浏览器按你写的 minmax(280px, 1fr) 去算列数，但若子项内部有未约束的尺寸，单格实际宽度远超 280px，容器就塞不下第二列。
典型诱因包括：<img> 没设 max-width: 100%、子项用了 display: flex 且含 flex: 1（触发浏览器默认 min-width: auto）、文字块有 white-space: nowrap。
- 给所有子项加
min-width: 0（尤其嵌套了 flex 或 grid 的） -
<img>统一设max-width: 100%; height: auto; - 文字块加
overflow: hidden; word-break: break-word; - 检查父容器是否被上层
white-space: nowrap或未设width: 100%影响了真实宽度
IE 和 Safari 对 auto-fit 的兼容性陷阱
IE 完全不支持 auto-fit，只认 auto-fill（且行为略有不同）；Safari 直到 v16.4 才修复一个关键问题：当 auto-fit 遇到 fit-content() 或嵌套 minmax() 时，可能漏算轨道宽度，导致列宽压缩甚至归零。
- 错误现象：
Computed grid-template-columns显示为"none"，或 DevTools 中列宽为0px却仍有内容溢出 - 规避方案：避免在
minmax()第二参数用fit-content(300px)，改用300px或1fr - Safari 测试时，强制给网格容器设
width: 100%或min-width: 0，防止父容器收缩干扰轨道计算
