grid-template-columns用百分比时gap会叠加到总宽导致溢出，应改用fr单位或手动calc扣减；网格项width:100%无效且易冲突，应依赖justify-self:stretch；box-sizing需显式设置并验证；subpixel渲染下gap可能取整溢出，建议用clamp响应式控制。
grid-template-columns 用百分比时 gap 会直接加到总宽上
你写 grid-template-columns: 25% 50% 25%，三列加起来确实是 100%，但加上 gap: 10px 后，浏览器实际按 25% + 10px + 50% + 10px + 25% 计算——也就是 100% + 20px。这多出来的像素没地方放，只能横向溢出。
fr 单位能绕过这个问题，因为 fr 是在 gap 分配完之后、剩余可用空间里切分的。百分比却是在整个容器宽度（含 padding/border）上计算，和 gap 完全不协同。
- 别用百分比 + gap 混搭，尤其是固定容器宽度场景
- 改用
grid-template-columns: 1fr 2fr 1fr或minmax(200px, 1fr) 2fr等弹性写法 - 如果必须用百分比，手动扣掉 gap：比如三列 + 两个 gap，就写
calc((100% - 20px) / 3)，但维护成本高、响应式下易失效
子项 width: 100% 是相对于 content area，不是 grid track
你给网格项设 width: 100%，它其实是相对于父容器的内容区（content box）宽度，而不是它所在的那条 grid track 的宽度。而 track 宽度本身已经受 gap 推挤、padding 压缩、box-sizing 影响——所以 width: 100% 很可能比 track 实际可用宽度还大。
更关键的是：网格布局中，子项宽度本该由 track 控制，width 属于冗余干预，容易触发尺寸冲突。
立即学习“前端免费学习笔记（深入）”；
- 删掉所有网格项上的
width: 100%、max-width: 100% - 想让子项填满 track，靠
justify-self: stretch（默认值，通常不用写） - 如果子项内有文字或图片撑开，加
min-width: 0防止它拒绝收缩
box-sizing: border-box 没生效会让 gap “显得更宽”
很多人写了 box-sizing: border-box 就以为万事大吉，但这个属性不继承，且容易被重置样式或 scoped style 覆盖。一旦网格容器实际是 content-box，它的 width: 400px 就只管内容区，padding 和 border 会额外加出去，再叠上 gap，视觉溢出概率陡增。
验证方式很简单：打开 DevTools → 选中容器 → 看 Computed 面板里 box-sizing 最终值是不是 border-box。
- 显式给 grid 容器加
box-sizing: border-box，别依赖继承 - 如果用了 CSS-in-JS，确保选择器优先级足够，比如加
!important临时验证 - 避免在 grid 容器上同时设
padding和大gap，二者叠加极易临界溢出
gap 在 subpixel 渲染下可能向上取整
尤其在高 DPI 屏幕、页面缩放（如 110%）、或字体渲染微调时，浏览器对 gap 的像素计算可能出现 subpixel 偏差。比如理论 10px gap，在某些帧里被渲染为 10.3px，然后四舍五入成 11px——多个 gap 累加后，就多出 1–3px，刚好压垮原本勉强够用的布局。
这种问题无法通过肉眼调试发现，只有 Layout 面板里的精确尺寸才能暴露。
- 在 Chrome/Firefox DevTools 中勾选 “Show box model”，逐层看 padding / content / gap 区域的实际像素值
- 用
gap: clamp(0.5rem, 2.5vw, 1rem)替代固定像素，让间隙随视口流体缩放，减少 subpixel 累积 - 测试真机横竖屏切换，某些 WebView 对 subpixel 处理更激进
事情说清了就结束。真正难处理的不是 gap 本身，而是它和百分比、box-sizing、subpixel 渲染、以及你对“100%”的直觉预期之间那一层层嵌套的尺寸错位。
