父元素高度塌陷不是bug，而是position: absolute使子元素脱离文档流的规范行为；clearfix、overflow:hidden等BFC方案无效，因absolute元素不参与BFC高度计算；应先判断语义是否需撑高，再选用flex/grid、transform或JS动态计算等正确方案。
父元素高度塌陷不是 bug，是 position: absolute 的规范行为——子元素彻底脱离文档流，父元素自然“看不见”它。所有试图用 clearfix、overflow: hidden 或 display: flow-root “修复”的做法都无效，因为它们只处理浮动，和 absolute 无关。
为什么 overflow: hidden 和 display: flow-root 都不生效
这些方案本质是触发 BFC（块级格式化上下文）来包裹浮动内容，但 position: absolute 元素既不浮动、也不参与 BFC 的高度计算。你加了 .container { display: flow-root; }，DevTools 里能看到父容器盒模型被渲染出来了，但 getBoundingClientRect().height 依然为 0，下方兄弟元素还是紧贴顶部——因为它压根没把子元素当自己人。
常见误判现象：
-
clear: both写在父元素上：父元素自己没浮动，该声明完全无意义 -
overflow: hidden后背景色“展开”了：只是强制渲染了父容器自身盒模型，并未计入子元素占位，还可能裁剪弹层或阴影 -
display: flow-root用在 flex 父容器上：冗余且无效，flex 容器本身已是独立格式化上下文
该不该让父元素被撑高？先问语义
别急着写 JS 或加 CSS，先判断这个 absolute 子元素是否属于父容器的“内容逻辑”：
立即学习“前端免费学习笔记（深入）”；
- 右上角徽章、加载动画、背景浮层、遮罩层 → 不该撑高，保持原样就是正确行为
- 翻转卡片背面、下拉菜单主体、模态框内容区、轮播图标注 → 必须参与高度计算，此时应放弃
position: absolute
强行让装饰性元素撑开一个语义上无关的父容器，后续做响应式、加动画、改结构时，维护成本会指数级上升。
真正有效的三种落地方式（按推荐优先级）
选哪条取决于控制粒度、语义清晰度和是否受第三方限制：
- 改用
display: flex或display: grid+justify-content/align-items：比如右上角图标，用.parent { display: flex; justify-content: flex-end; align-items: flex-start; }，子元素仍在文档流中，自动参与高度计算 - 改用
position: relative+transform: translate()：保留视觉偏移意图（如transform: translate(10px, -20px)），但元素仍在流内，父容器能自然感知其尺寸 - JS 动态计算并写入
min-height：仅当非用absolute不可（如复杂动画层叠、图表库限制）。关键不是读offsetHeight，而是遍历所有absolute子元素，取el.getBoundingClientRect().bottom最大值，减去父容器getBoundingClientRect().top，再加padding-top和border-top；必须用ResizeObserver监听，不能只靠DOMContentLoaded
纯 CSS 占位方案最容易被低估
当子元素位置固定、尺寸可控（如固定高度徽章、等比例图标），用 padding-bottom 或伪元素比写死 height 更安全：
-
padding-bottom: 24px：不阻断溢出，兼容字体缩放和横竖屏切换 -
border-bottom: 24px solid transparent：若父容器已有边框，可复用占位 -
::after { display: block; height: 24px; }：效果等同空<div></div>，但更轻量
注意：这些会让父容器实际占用空间变大。如果父容器在 flex 布局中，或周围有 margin，可能影响对齐——这不是缺陷，而是你主动选择了“占位”，得承担对应布局责任。
