嵌套 Grid 中的“边距叠加”是子项内部 margin 合并所致，非 gap 失效；gap 仅作用于直接子项之间，而 p 等元素的 margin-top/margin-bottom 仍按块级流合并取大值。
嵌套 Grid 中的“边距叠加”不是 gap 失效，而是你误把 margin 当成了布局间距控制手段——它根本不会和 gap 叠加，只是在子项内部偷偷合并，导致视觉错位。
为什么 grid-gap 设了 24px，p 标签之间还是只显示 16px
因为 gap 只作用于网格容器的**直接子项之间**，而子项内部的 p 元素仍走标准块级流，它们的 margin-top 和 margin-bottom 会按规则合并（取较大值）。比如两个 p 分别设了 margin-bottom: 20px 和 margin-top: 12px，实际垂直间距是 20px，不是 32px。
DevTools 的 “Computed” 面板里看到的 margin-top 值若被标记为 “collapsed”，就是证据。常见于用了 normalize.css 或现代 UI 库的项目，p、h2 等默认带 margin。
- 响应式断点切换时，如果只改了
grid-template-columns却没重置子项内部margin，问题会突然复现 - 嵌套层级越深，这种“看不见的合并”越容易叠加，形成“双重重叠”陷阱：小屏下单列堆叠后，外层
gap+ 内部margin-collapse同时生效，间距忽大忽小
嵌套 Grid 容器里该给谁加 display: flow-root
必须加在**包含那些会重叠的子元素的父容器上**，且这个容器得是这些子元素的**直接父级**。
立即学习“前端免费学习笔记（深入）”；
例如：
.grid-item {
display: grid;
gap: 8px;
}
.grid-item > p {
margin: 16px 0;
}
重叠发生在 .grid-item 内部的 p 之间，所以要修复，就得让 .grid-item 自身触发 BFC：
-
.grid-item { display: flow-root; }✅ 正确：BFC 隔离了内部p的margin -
.grid-item > p { display: flow-root; }❌ 错误：每个p自己建 BFC，但兄弟间margin仍可能合并（取决于是否相邻） - 给外层 Grid 容器加
display: flow-root没用——它不作用于孙子级的p
比 display: flow-root 更轻量的替代方案
padding-top: 0.1px 比 border-top: 1px solid transparent 更轻量，两者都能打断父子 margin-collapse，但前者不引入额外视觉干扰或尺寸变化。
特别适合封装好的组件场景——你无法改子元素 margin，只能动父容器样式。
- 适用于第三方组件包裹的 Grid 项，例如：
<antdcard><div class="grid-item"></div></antdcard>，此时在.grid-item上加padding-top: 0.1px就能稳住顶部空隙 - 注意：不能写成
padding: 0.1px 0，否则左右padding也会生效，可能影响对齐 - 如果项目需兼容 IE 或老版 Safari，
padding-top: 0.1px是比display: flow-root更稳妥的选择
真正该禁用 margin 的地方
子项内部需留白，优先用 padding；需对齐，用 align-self/justify-self。不要在嵌套 Grid 的子项内部用 margin-top/margin-bottom 控制间距。
如果你看到子项之间仍有空隙，那大概率是 gap 值，不是 margin ——Grid 容器的直系子项根本不会发生 margin-collapse，它的 margin 对齐、间距控制全部让位于 gap。
- 子项自身的
margin仍会影响它内部内容与边框的距离，或与容器padding的相对位置 - 若必须保留子项内
margin，可在父容器加border-top: 1px solid transparent阻断合并 - 调试时最容易忽略的是高 DPI 屏幕或缩放 125% 下的 subpixel 四舍五入，
gap渲染可能多占 1–2px，别拿 DevTools 的 “box model” 总宽和 “Computed” 里的width直接比
