gap只作用于网格项之间，不阻止子元素内部margin合并；子元素的margin仍按盒模型规则合并，与gap无关。
grid容器内设了gap，但子元素的margin还在合并
gap只作用于网格项之间的间隙，它不会阻止子元素内部的margin collapse。如果你在grid-item里又套了一层div，并给它设了margin-top，这个margin仍会和兄弟元素的margin-bottom合并——因为gap不接管子元素的盒模型逻辑。
常见错误现象：.grid-item > p之间看起来只有20px间距，哪怕gap: 30px已生效；DevTools里看到计算后的margin-top和margin-bottom被合并了。
- gap是网格布局层的“轨道间留白”，而margin是元素自身的外边距，二者运行在不同层级
- 嵌套越深，越容易误以为gap能“穿透”到子元素内部——它不能
- 若子元素是块级且处于标准流，它们之间的垂直margin仍按原始规则合并
父容器是grid，子元素用margin控制间距反而引发错位
当grid容器设置了justify-content: center或align-content: start，再给子项加margin-left或margin-top，可能造成视觉偏移叠加：gap已居中对齐，margin又额外推远，最终位置不可控。
更隐蔽的问题是：某些CSS重置库（如Normalize.css）会给p、h1等默认设margin，嵌套进grid后这些margin未被重置，就会和gap形成“双重间距”或意外合并。
- 检查子元素是否继承了全局
margin，可在DevTools的Computed面板过滤margin确认 - 避免在grid项内部用
margin做主要间距控制，优先用padding或子级flex/gap - 若必须用margin，统一约定方向（如只设
margin-bottom），并确保父容器不参与合并（加border-top: 1px solid transparent）
grid-auto-flow: dense + margin混用导致重叠不可预测
启用grid-auto-flow: dense后，浏览器会尝试填满空缺轨道，但若此时某个网格项内部有大margin（比如margin-bottom: 100px），它可能把后续项“挤”进本该空着的区域，造成看似重叠——其实是dense模式强行重排+margin撑开空间共同导致的。
典型场景：时间轴列表中，每个.event设了grid-row: span 2，但其中一项因内容多触发了大margin-bottom，dense模式就把它后面本该占第3行的项拉到了第2行末尾，视觉上压在前一项上。
-
grid-auto-flow: dense本身不处理margin，但它放大了margin对布局节奏的影响 - 调试时先临时关掉
dense，看是否还重叠；若消失，问题大概率出在margin与自动流的交互上 - 密集布局下，建议所有网格项用
min-height+overflow: hidden约束高度，避免margin无序撑开
用gap替代margin时要注意兼容性和语义断层
gap在grid/flex容器中是推荐方案，但它无法替代所有margin场景。比如你想让某个网格项“脱离常规间距”突出显示，用gap做不到——它对所有项一视同仁；而margin可以单独作用于某一个。
另一个坑是：部分旧版Safari（≤15.4）对gap支持不稳定，若同时写了gap和margin，可能只渲染margin，造成预期外的空白或挤压。
- 不要用
gap去“覆盖”或“抵消”已存在的margin，先清空子元素的margin再上gap - 对需要差异化间距的项，改用
grid-column/grid-row手动定位，或包裹一层flex容器控制内部间距 - 若需兼容老浏览器，可用
@supports (gap: 0)做特性检测，fallback回margin方案
最易被忽略的是：gap和margin不是互斥开关，而是分属不同布局层级的控制手段。混淆它们的作用域，比写错grid-column起止线更容易引发难以复现的视觉错乱。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
