padding-bottom 配合负 margin-bottom 能“骗过”高度计算，是因为浏览器先按 content+padding 计算父容器高度，再用 margin 做视觉位移，从而在视觉上实现底部对齐而非真实等高。
为什么 padding-bottom 配合负 margin-bottom 能“骗过”高度计算？
因为 CSS 盒模型中，padding-bottom 会撑开父容器高度，而 margin-bottom: -Xpx 会让子元素视觉上“上提”，但不改变父容器已计算出的高度——两者叠加，就让父容器维持了由 padding “撑出来”的那个等高基准。
这个技巧本质是利用浏览器渲染顺序：先按 content + padding 算高度，再用 margin 做视觉位移。它不是真正的“等高”，而是让所有子项在视觉上对齐底部、内容区看起来一样高。
常见错误现象：margin-bottom 设得不够大，子项底部仍参差；或父容器加了 overflow: hidden，把负 margin 溢出部分裁掉了。
- 只适用于已知最大内容高度（或能预估）的场景，比如卡片列表、导航栏项
-
padding-bottom值必须 ≥ 所有子项中最高内容的实际高度 - 父容器不能设
height固定值，否则会压垮布局 - 子项需设
position: relative或display: inline-block，否则负 margin 可能失效
怎么写一个可用的等高卡片组（CSS-only）
假设三张卡片，内容高度不一，但希望底部对齐、整体高度一致。关键不是拉伸内容，而是统一“底边线”位置。
立即学习“前端免费学习笔记（深入）”；
.card-group {
display: flex;
}
.card {
flex: 1;
padding-bottom: 120px; /* 预估最大内容高度 */
margin-bottom: -120px; /* 必须和 padding-bottom 相等 */
position: relative;
}
.card > * {
position: relative;
z-index: 1;
}使用场景：后台仪表盘的指标卡片、产品页的规格对比模块。不适合内容高度完全不可控的 CMS 场景（比如用户随意粘贴长图+多段文字）。
- 如果卡片内有图片，记得给
img加max-width: 100%和height: auto，避免撑破预设高度 - 移动端需重新估算
padding-bottom值，不能直接复用 PC 端数值 - 不要在
.card上同时用min-height，它会和负 margin 冲突导致空白错位
和 flex: 1 或 grid 比，这招有什么硬伤？
它不响应内容变化：一旦某张卡片内容动态增长超过预设高度，底部就会塌陷，且不会触发重排。而 display: grid 或 flex 的 align-items: stretch 是真等高，自动适应。
兼容性方面，负 margin 和 padding 在 IE8+ 都支持，但 flex 和 grid 在 IE10/11 里行为异常（尤其 grid），所以老项目还在用这套“土办法”。
- 性能影响极小，纯 CSS 渲染，无 JS 干预
- 无法配合
transition做高度动画（padding/margin 同时动会抖） - 无障碍阅读器可能误判结构层次，因为视觉布局和 DOM 顺序不一致
遇到 margin-bottom 失效，先查这三处
负外边距不是万能的，很多“没反应”其实是被其他规则压制了。
- 父容器设了
overflow: hidden或auto，直接剪掉溢出部分——去掉或改用visible - 子项用了
float，浮动元素的 margin 行为特殊，优先转成display: inline-block或flex - 存在相邻兄弟元素的
margin-collapse，比如上面有个h3，它的下边距和卡片的负边距合并了——加overflow: hidden到父容器或触发 BFC 即可隔离
真正难调的不是代码本身，而是得反复估算那个 padding-bottom 值：太小，底边不齐；太大，顶部留白难看。多数时候，宁可多留 10px，也别少留 1px。
