grid子项的margin看起来“没用”是因为其直系子项脱离普通文档流，垂直方向margin-top/margin-bottom不参与间距计算；真正控制间距的是gap属性，margin仅影响自身盒模型尺寸。
Grid子项的margin为什么看起来“没用”？
因为Grid容器的直系子项（即直接放在display: grid父容器里的元素）已脱离普通文档流，垂直方向的margin-top和margin-bottom完全不参与间距计算——不是被合并，而是根本失效。你写margin: 20px，元素自身盒模型尺寸照常撑开，但相邻子项距离不会因此变大。
真正控制子项间距的是gap（或row-gap/column-gap）。这是Grid布局的设计契约：间距由容器统一分配，而非子项各自声明。
- 若同时设了
gap: 16px和子项margin: 10px，实际间距会是16px + 10px + 10px = 36px（上下/左右各叠加），容易造成意外留白 -
margin-left/margin-right在水平方向仍生效，但仅影响子项自身位置（如向左偏移），不改变列间间距 - 负
margin（如margin-top: -10px）可能让子项上移，但不会“拉近”上方邻居——上方邻居的位置由gap和轨道高度决定
什么时候必须保留子项的margin？
当需要微调单个网格项内部结构，或嵌套布局中孙级元素需独立控制间距时。margin对Grid子项自身盒模型始终有效，只是不作用于网格轨道分配逻辑。
典型场景：
- 卡片内标题与内容之间用
margin-bottom: 12px分隔，不影响卡片之间的gap - 网格项里嵌套Flex容器，其子元素用
margin-right做横向微调 - 需要让某个网格项“破格”延伸（如横跨两列后右侧留空），靠
margin-right: auto或负值实现
注意：margin在此类用途中不与gap冲突，因为它作用于子项内容区域，而非网格轨道间隙。
box-sizing和padding/border如何影响Grid子项尺寸？
Grid轨道分配的空间是“可用空间”，而子项最终渲染尺寸取决于盒模型计算。若未设box-sizing: border-box，且子项有padding或border，会导致内容溢出轨道。
例如：grid-template-columns: 200px分配一列，子项设width: 100%; padding: 16px; border: 2px solid #000，实际宽度为200px + 32px + 4px = 236px，触发横向滚动或重叠。
- 务必全局设置
* { box-sizing: border-box }，让width包含padding和border -
margin永远不参与width/height计算，无论box-sizing取值 - 如果依赖
gap做精确留白，就别在子项上加padding模拟间距——改用gap更可控
嵌套Grid或混合布局时margin-collapse还会发生吗？
会，但只发生在非Grid直系后代上。Grid容器的子项不触发外边距合并，但它的子元素（即孙级块元素）仍在普通文档流中，相邻兄弟块依然会合并margin-top/margin-bottom。
比如一个Grid子项是<div class="card"></div>，里面有两个<p></p>段落，它们之间的垂直外边距仍会合并。
- 解决方法不是给每个
<p></p>加margin，而是用padding（不合并）或设overflow: hidden触发BFC - 更干净的做法：把
.card也设为display: grid或display: flex，让其子元素脱离BFC，彻底规避合并 - 不要依赖
margin来“修复”嵌套层级的间距问题，优先用容器级布局属性（gap、flex-gap、padding）统一控制
最易忽略的点：开发者常以为用了Grid就一劳永逸，结果在子项内部用margin布局时，又掉进传统文档流的坑里——盒模型规则从未消失，只是执行主体变了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
