gap不计入容器宽高但占用content area，从内容区扣除；它仅作用于网格轨道间，与margin叠加导致间距翻倍，且受subpixel渲染影响。
gap 不计入容器的 width/height，但会占用容器内部可用空间。它不是“额外加宽”，而是从 content area 里硬生生切出一块来留给轨道间隙——这点常被误读为“gap 撑大了容器”。
gap 的尺寸归属：它只影响 grid track 之间的空隙，不改变容器盒模型边界
浏览器计算 width 和 height 时，gap 本身不参与 border box 或 padding box 的尺寸累加。但它的作用位置在 grid tracks 之间，属于 content area 内部的刚性占位：
-
gap值会从容器的content area宽度中扣除（比如grid-template-columns: 1fr 1fr+gap: 20px，两列间一个 gap → 总共减去 20px） - 如果容器设了
width: 400px和padding: 10px，content area 实际只剩 380px；再扣掉 gap 占用部分，剩余才分给 fr 轨道 - DevTools 的 Layout 面板里，
gap显示为独立色块（通常浅灰），位于两列/两行之间，不延伸到容器 border 外侧
为什么看起来“容器变宽了”？box-sizing 和 padding 是真凶
视觉上溢出或滚动条出现，90% 情况下和 gap 无关，而是 box-sizing 未生效 + padding 叠加导致 content area 过小：
- 只写
* { box-sizing: border-box; }不够——display: grid容器必须显式设置box-sizing: border-box，否则 padding/border 仍按content-box计算 -
padding和gap是两个物理区域：padding 在容器内边，gap 在子项轨道间，二者叠加会快速吃掉 content area - 验证方式：打开 DevTools → Computed 面板 → 查看该容器的
box-sizing是否为border-box，再看 Layout 面板中 padding 区域和 gap 区域是否重叠挤压
fr 单位计算不准？其实是 gap 扣减后剩余像素被舍入了
fr 本身没 bug，问题出在浏览器把“扣掉 gap 后的剩余像素”做整数分配时的舍入行为：
- 容器宽度是 799.5px，三列
1fr 1fr 1fr+gap: 10px（两个 gap → -20px），剩余 779.5px → 三等分 ≈ 259.833…px → 浏览器四舍五入成 260/260/259 - 解决办法不是改
fr，而是确保容器 width 是整数（检查父级缩放、字体度量、subpixel 渲染干扰） - 避免混用单位：
grid-template-columns: 200px 1fr 1fr改为minmax(200px, 1fr) 1fr 1fr，让所有轨道都参与弹性分配
gap 和 margin 混用：间距翻倍还错位
gap 是容器级轨道间隙，margin 是子项自身外边距，两者完全不抵消：
- 设了
gap: 1rem又给子项加margin: 0.5rem→ 实际间距 = 1rem（gap）+ 0.5rem（margin-top）+ 0.5rem（margin-bottom）= 2rem - 首尾子项的
margin会溢出容器边界，造成不对称留白；而gap始终严格对齐轨道边缘 - 需要“某一项额外留空”？只给那个元素加
margin，但确认父容器没设align-items: stretch（否则 margin 可能被拉伸失效）
真正容易被忽略的是：gap 的数值在 subpixel 渲染、高 DPI 屏幕、页面缩放下可能被向上取整，尤其当容器 width 接近临界值时，1px 的偏差就会让整行换行或触发横向滚动——别猜，直接看 DevTools Layout 面板里的实际像素值。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
