Grid子项margin不合并是因脱离常规流、不参与BFC合并，而是相加；gap与margin叠加易致溢出，推荐优先用gap控制间距。
Grid容器的直接子元素（即网格项）之间，margin确实不会合并——这不是“修复”或“例外”，而是CSS规范明确规定的布局行为。
Grid子项的margin为什么天然不合并
根本原因在于：网格项脱离了常规文档流（normal flow），不再参与块格式化上下文（BFC）中的margin合并逻辑。它们是独立参与网格轨道分配的“网格盒”（grid box），每个margin都完整保留、独立计算。
- 相邻网格项的
margin-bottom和margin-top会**相加**，不是取最大值 - 父容器（grid container）与首个/末个网格项之间的
margin也不会合并——因为网格项不触发父子margin合并条件 - 这个规则只适用于
display: grid容器的**直接子元素**；子元素内部的嵌套块级元素（如p、div）仍按常规流合并
为什么DevTools里看起来像“合并了”
常见错觉来源是gap和margin叠加后视觉混淆，或误读Computed值：
- 设置了
gap: 16px又给网格项加margin: 8px，实际间距是24px（不是覆盖，也不是合并） - 用
justify-content: center时，margin-left: auto能右对齐，但margin-top: 20px可能被align-items: stretch压制，导致“没生效”的错觉 - 在Computed面板中看到
margin-top: 0，未必是被合并了，可能是该值被grid-row-start或align-self覆盖了布局作用
Grid里该不该用margin控制项间距离
不推荐。虽然margin不合并，但它引入不可控变量：
立即学习“前端免费学习笔记（深入）”；
-
margin会溢出容器边界（比如margin-right超出最后一列轨道） - 与
gap共存时叠加，容易撑破容器宽度，尤其在响应式场景下 - 首项/末项的
margin无法被gap统一管理，需额外选择器重置（如:first-child { margin-left: 0; }） - 嵌套更深时（如网格项内再套Flex），
margin语义模糊：你到底想推哪一层？
真正要警惕的是嵌套内部的margin合并
Grid容器本身不合并子项margin，但子项内部的结构照旧遵循盒模型规则：
- 一个网格项里放两个
p，它们的垂直margin依然会合并 - 如果子项是
div且没设overflow或border，它的margin-top可能“冒”到网格容器外（表现为顶部空白） - 此时应优先在子项上加
display: flow-root或padding-top: 1px，而不是在p上疯狂写margin-top: 0
最容易被忽略的一点：gap只管轨道之间，margin只管元素边界——它们不在同一层工作。混用时别指望浏览器“智能协调”，它只会老老实实把数字加起来，然后等你发现横向溢出或对齐偏移。
