父元素高度塌陷不是bug，而是浮动元素脱离文档流的必然结果；子元素设float: left/right后，父容器无法感知其高度，导致背景、边框及后续元素错位。
父元素高度塌陷不是 bug，是浮动（float）脱离文档流的必然结果；只要子元素用了 float: left 或 float: right，父容器就“看不见”它们的高度——背景、边框、后续兄弟元素错位，全是因为这个。
为什么 clear: both 加在浮动元素自己身上没用
很多人把 clear: both 写在浮动子元素上，比如：.item { float: left; clear: both; }。这完全无效，因为 clear 的作用是“让当前元素下移，避开前面的浮动”，它不改变父容器的布局上下文，也不参与父容器高度计算。
真正起作用的位置，必须是浮动流之后、仍在普通文档流中的一个块级元素（或伪元素）。它得“站住”，才能把父容器底部拉下来。
-
clear只对块级元素生效，display: inline或未设宽高的元素不会响应 - 加了
clear: both但父容器仍塌陷？先检查那个“清除元素”是否被display: none、visibility: hidden或height: 0且overflow: hidden给吞掉了 - Vue/React 中动态添加
class="clearfix"时，若样式还没加载完，会出现闪动塌陷——建议用style内联或确保 CSS 提前注入
clearfix 伪元素怎么写才真正生效
复制粘贴一段 .clearfix::after 却没效果，大概率是漏了关键条件。标准写法必须同时满足三件事：content 非空、display 是块级、clear: both。
立即学习“前端免费学习笔记（深入）”；
推荐写法（兼容 IE8+，无副作用）：
.clearfix::before,
.clearfix::after {
content: "";
display: table;
}
.clearfix::after {
clear: both;
}
注意：display: table 比 block 更稳妥，某些旧版 IE 下 block 仍不撑高；content: "" 不能省略或写成 content: none，否则伪元素根本不渲染。
- 如果父元素本身已设
overflow: hidden，clearfix会失效——BFC 触发逻辑冲突，优先级混乱 - 预处理器（如早期 Less）可能把
::after编译成:after，导致现代浏览器重复触发，建议显式写双冒号 + 单冒号兼容 - Vue 的
scoped样式下，::after选择器可能被属性选择器污染，需用/deep/或::v-deep确保穿透
overflow: hidden 能快速解决，但代价是什么
给父元素加 overflow: hidden 是最快方案，它强制触发 BFC，让父容器重新包含浮动子元素。但它不是“清除浮动”，而是“绕过问题”。
- 会裁剪所有溢出内容：下拉菜单、
position: absolute偏移过大的提示框、负margin元素，全被切掉 -
overflow: auto在 Safari 或某些移动端 WebView 中，即使内容没溢出也可能意外出现滚动条 - 当父容器本身需要
overflow: visible（比如 tooltip 容器、动画外延区域），这条路直接堵死 - Flex/Grid 布局中加
overflow: hidden依然有效，但属于冗余操作——这些布局天然不塌陷，没必要触发 BFC
display: flow-root 是现代最优解，但别忽略兼容边界
这是专为解决塌陷设计的值，语义清晰、无副作用：.container { display: flow-root; } —— 一行代码创建新 BFC，不裁剪、不滚动、不影响子元素定位行为。
但它不是万能的：
- IE 完全不识别，会退化为
display: block，此时仍塌陷；若项目还需支持 IE11，不能单独依赖它 - Chrome 64+/Firefox 58+/Safari 15.4+/Edge 79+ 才支持，2026 年已覆盖绝大多数场景，但内网系统或老设备仍可能踩坑
- 它只解决浮动塌陷，对
position: absolute子元素完全无效——后者根本不在文档流里，BFC 也“抓不住” - 调试时容易忽略：塌陷往往发生在嵌套多层的父容器上，
flow-root必须加在**直接包裹浮动子元素的那个父级**，加错层级等于白写
真正容易被忽略的是：很多人花时间调 float 子元素的 margin 或 width，却忘了问题根子在父容器的布局上下文；还有人把 clearfix 类加在 grandparent 上，而实际浮动只发生在 child 层——层级错，一切白搭。
