margin合并是CSS规范规定的垂直相邻块级元素的margin-top与margin-bottom取较大值合并的行为；仅发生在普通文档流中块级盒子间，水平margin不合并，可通过触发BFC、改display、用padding或Flex/Grid布局解决。
什么是 margin 合并？浏览器真在“帮你省事”
margin 合并（Margin Collapse）不是 bug，是 CSS 规范明确规定的默认行为：相邻块级元素的垂直 margin-top 和 margin-bottom 会合并成一个，取其中较大的那个值。它只发生在普通文档流中的块级盒子之间，且方向必须是垂直的（margin-left/margin-right 永远不合并）。
常见错误现象包括：
- 两个
<p></p>元素间看起来只有 20px 间距，但各自写了margin: 20px - 父元素设置了
margin-top，结果整个父容器“飘”上去了，而不是子元素相对父容器偏移 - 用
display: flex或display: grid包裹后，margin 突然“失效”——其实是没触发合并条件，而非失效
怎么确认是不是 margin 合并导致的？
别猜，用开发者工具直接看。打开 Elements 面板，选中元素，观察 Styles 侧边栏里 margin 的计算值（Computed 标签页更直观）。如果两个相邻元素的垂直 margin 显示为单个数值（比如都是 20px，但实际间距只有 20px 而非 40px），基本就是合并了。
立即学习“前端免费学习笔记（深入）”；
关键判断点：
- 两个元素必须是**块级、处于普通流、无 BFC 边界、无间隙（如换行符/空格不影响，但
display: inline-block会破坏）** - 父-子间合并只发生在**父元素没 border/padding、没内容、没清除浮动、且子元素是第一个或最后一个块级子元素**时
-
margin: 0 auto是水平居中，和合并无关；margin: 10px 0才可能参与垂直合并
真正能用的 4 种解决方式（按推荐顺序）
别一上来就加 overflow: hidden，先看场景再选方案。不同方法副作用差异很大：
-
触发 BFC（最常用）：给父元素加
overflow: hidden、display: flow-root（推荐，语义清晰且无副作用）、float: left（慎用，会脱离文档流） -
改 display 类型：把子元素设为
display: inline-block或display: table-cell，它们不参与块级合并（但会引入基线对齐等新问题） -
用 padding 替代 margin：父元素用
padding-top代替子元素的margin-top，完全绕开合并逻辑（适合固定结构） -
Flex/Grid 布局：父元素设
display: flex或display: grid，子项的margin不再合并（但注意gap是更合适的间距控制方式）
示例：解决经典父元素“塌陷”问题
.parent {
display: flow-root; /* 推荐，比 overflow:hidden 更干净 */
}
.child {
margin-top: 20px;
}哪些情况 margin 就是不该合并？小心隐式陷阱
有些写法看似正常，其实悄悄破坏了合并条件，导致行为不一致：
- 父元素有
border: 1px solid transparent—— 这会阻止父子 margin 合并，但很多人误以为“透明边框没影响” - 子元素前面有注释节点或文本节点（哪怕只是换行）—— 在某些旧版渲染中可能干扰合并判定
-
margin值为auto（如margin: auto）不参与合并，但它会把块级元素变成“块级替换元素”，表现完全不同 - 使用
transform: translateY()模拟位移时，视觉上像 margin，但完全不触发合并，也**不占文档流空间**——这点容易被忽略
复杂点在于：合并规则嵌套层级深，父子、兄弟、空元素、匿名文本都会影响。遇到拿不准的情况，优先用 display: flow-root 或 gap，比硬调 margin 更可控。
