gap本身不会导致换行，真正触发换行的是grid-auto-flow和轨道定义；它仅从容器尺寸中预先扣除间距，影响minmax()计算基数与隐式网格生成。
gap本身不会导致换行，真正触发换行的是grid-auto-flow和轨道定义
设置gap后子元素“突然换行”，不是gap在起作用，而是它暴露了原本被忽略的布局逻辑：Grid 容器在没有显式定义行/列轨道时，会依赖grid-auto-flow（默认row）和隐式网格生成规则来安放子项。一旦gap占掉空间，剩余可用宽度变小，原本能挤在一排的子项就可能被推到下一行。
-
grid-template-columns: repeat(auto-fit, minmax(200px, 1fr))+gap: 16px→ 实际每列最小需 200px + 16px（右侧gap），但minmax()只管内容区，gap是额外扣除的，容易让“刚好够放3个”的容器只能放下2个 - 显式写死
grid-template-columns: 1fr 1fr 1fr却只放4个子项，第4个仍会按grid-auto-flow: row进入第二行——gap只是让这一行看起来更“松”，并非换行原因 - 用
grid-auto-flow: column时，gap会先扣列间距，可能导致隐式行高度异常撑开，视觉上像“错行”
检查grid-auto-flow值是否与预期一致
很多人以为“写了gap就有网格感”，却没意识到grid-auto-flow才是决定子项怎么排队的开关。它的默认值row会让子项从左到右、满了换行；设成column则从上到下、满了换列——而gap只是把每一步的间隔拉开了。
- 想严格控制行列数？必须配合
grid-template-rows或grid-template-columns显式定义轨道，而不是只靠auto-fit/auto-fill -
grid-auto-flow: dense可能让空缺被回填，但不会改变换行逻辑；它只影响已定位项之后的自动放置顺序 - 用开发者工具勾选「Grid Overlay」，看浏览器实际画出的网格线——如果线数远超你预期，说明隐式网格已介入，
gap只是让这些隐式轨道更明显
gap对minmax()中fr单位的“隐形压缩”效应
gap不是加在item外面的边距，而是从容器总宽高里**先切走**一部分，再把剩下的空间分给tracks。这对minmax(200px, 1fr)这类弹性定义影响极大：fr计算基数变小了，可能导致某列实际宽度跌破minmax()的下限，进而触发隐式行生成。
- 例如容器宽600px，
gap: 20px，三列1fr 1fr 1fr→ 每列分配到的是 (600 − 20×2) ÷ 3 = 186.67px（注意：n列有n−1个列间隙） - 若你期望每列≥200px，那这个布局必然失败，第3个item会被挤到第二行——这不是bug，是fr单位按规则执行的结果
- 解决办法：改用
minmax(200px, max-content)，或把gap值纳入minmax下限估算（如minmax(calc(200px + 10px), 1fr)，但需谨慎，gap不参与calc上下文）
子元素display: contents会破坏gap的视觉连续性
当某个子元素设了display: contents，它从渲染树中消失，不再作为独立grid item存在。此时它前后的item之间，gap仍然存在，但因为中间“缺了一块”，视觉上会像换行错位或间距突变。
立即学习“前端免费学习笔记（深入）”；
- 典型场景：用
<span></span>包裹文字并设display: contents，父容器是grid，相邻<div>之间gap正常，但span所在位置无节点，左右div的间距仍是gap值，没有“中间项”来承接对齐基准 <li>用Computed面板看该位置的<code>row-gap/column-gap是否仍生效——是的，但gap作用对象已变化 - 避免方案：不用
display: contents，或改用visibility: hidden+position: absolute等不影响布局流的方式隐藏
真正容易被忽略的点在于：
gap从不主动换行，但它会放大grid-auto-flow、minmax()和display: contents带来的副作用。调试时别盯着gap看，要顺着它暴露出来的隐式行为往回查。
