gap不增加容器总宽度，仅从content area中扣除空间；列数为n时列间gap数量为n−1，需在计算单列宽时预先减去全部gap值。
gap本身不增加容器总宽度，但会吃掉content area空间
很多人看到滚动条或横向溢出，第一反应是“gap把容器撑宽了”，其实不是。浏览器计算容器总宽度时，gap不参与width或border-box尺寸累加；它只是强制在grid track之间留白——而这个留白，必须从容器的content area里抠出来。
真正出问题的地方在于：你写了width: 400px + padding: 16px，content area只剩368px；再放两列各180px + 一个gap: 20px → 180 + 20 + 180 = 380px，已经超了。
-
grid-template-columns定义的是轨道（track）可用宽度，不是子项最终渲染宽度 - 子项是否填满轨道，取决于它的
box-sizing和自身width/min-width - 如果你用
1fr，浏览器会先扣掉所有gap、border、padding，再均分剩余空间
用grid-template-columns显式计算时，必须减去gap总量
当你要精确控制列宽（比如三列等宽+固定间距），不能只写grid-template-columns: 100px 100px 100px然后加gap: 12px就完事——因为三列有**两个**列间gap，总共要预留2 × 12px = 24px。
正确做法是反向推算单列可用宽度：
立即学习“前端免费学习笔记（深入）”；
.grid {
width: 360px;
padding: 0; /* 先清空干扰 */
display: grid;
/* 三列，每列实际占多少？(360 - 2×12) ÷ 3 = 112px */
grid-template-columns: 112px 112px 112px;
gap: 12px;
}- 列数为
n时，列间gap数量是n − 1；行同理 - 如果用了
fr单位，浏览器自动帮你算，但前提是容器content area足够大——否则fr会收缩到minmax(auto, 1fr)下限 - 混合单位如
200px 1fr时，先扣掉200px和gap，再把剩余给1fr
box-sizing: border-box没生效是溢出最常见原因
即使你把grid-template-columns算对了，子项仍可能撑破轨道——因为子项默认box-sizing: content-box，它的padding和border会额外加在轨道宽度之外。
验证方式很简单：打开DevTools → Elements → 选中某个网格子项 → 看Computed面板里的box-sizing值是不是border-box。如果不是，大概率被以下情况覆盖：
- 全局重置样式（如
normalize.css）没命中display: grid容器的子项 - CSS-in-JS中选择器优先级不够，比如
.item { box-sizing: border-box; }被div { box-sizing: content-box; }盖掉了 - 父容器设了
box-sizing，但该属性**不继承**，子项必须单独声明
最稳妥的做法仍是全局兜底：
* { box-sizing: border-box; }
旧版Safari中gap不生效，别只靠gap写死间距
如果你的项目需兼容iOS 15.4及更早系统，gap可能完全不解析——尤其当它和grid-template-areas混用时。此时仅靠grid-template-columns计算宽度也没用，因为间隙根本没加进去。
双写是唯一可靠方案：
.grid {
display: grid;
grid-template-columns: repeat(3, 1fr);
grid-gap: 12px; /* Safari ≤15.4 兜底 */
gap: 12px; /* 主力支持 */
}-
grid-gap在Chromium 107+/Firefox 109+已标记为deprecated，但Safari仍依赖它 - 不要用
%或em写gap值，某些旧引擎会四舍五入错误，导致最后一列错位1–2px - 高DPI屏或页面缩放时，subpixel gap渲染可能向上取整，建议用偶数px值（如
8px而非7px）
真正难处理的不是gap本身，而是它和padding、border、box-sizing、fr分配逻辑叠在一起时，哪一层先扣、哪一层后算——这些顺序在不同浏览器中基本一致，但一旦混用CSS-in-JS或scoped style，就很容易在某一层悄悄失效。
