浮动元素无法撑开父容器，是因为其脱离文档流导致父容器高度塌陷；推荐用伪元素clearfix清除浮动，现代布局应优先选用flex或grid。
浮动元素无法撑开父容器，是因为它彻底脱离了文档流——父容器在布局计算阶段根本不会把它纳入高度或宽度的考量范围。这不是 bug，是 CSS 规范里写死的行为。
为什么 float 会让父容器高度塌陷成 0
只要子元素设置了 float: left 或 float: right，它就从普通文档流中被抽离。父容器计算 height: auto 时，只看还在流里的内容：比如文字、未浮动的 <div>、<code>inline 元素。哪怕你给浮动子元素写了 height: 300px，父容器也视而不见。
-
min-height和width: 100%都无效——前者依赖内容撑高，后者只管水平方向，和高度无关 -
clear: both加在父容器上完全没用，因为clear只对参与同一浮动上下文的兄弟元素生效 - 开发者工具里看到父容器
height是 0、背景色不显示、后续元素“叠”上来，都是同一症状的不同表现
触发 BFC 是怎么让父容器“重新看见”浮动元素的
BFC（块级格式化上下文）不是魔法，而是一套独立的布局环境。一旦父容器成为 BFC 容器，它的内部布局规则就变了：它必须包含所有子元素的盒模型，包括浮动元素的高度和宽度。
-
overflow: hidden、overflow: auto、display: flow-root都能触发 BFC，但行为不同 -
overflow: hidden最常用，但它会裁剪所有溢出内容（比如下拉菜单、带负 margin 的装饰、绝对定位弹窗） -
display: flow-root是专为此设计的值，无裁剪副作用，Chrome 58+/Firefox 57+/Safari 15.4+ 支持，但 IE 完全不支持 - 别用
position: absolute或float自身来触发 BFC——这会让父容器自己也脱离文档流，问题上移
clearfix 伪元素方案为什么有效，以及哪些地方容易漏掉
.clearfix::after 不是靠“触发 BFC”，而是靠插入一个真实参与文档流的块级锚点，把父容器底部“拉下来”。关键不在概念，而在渲染链是否完整。
-
content: ""必须存在，否则伪元素根本不生成，整个方案失效 -
display: table比block更稳妥：避免 IE6–7 的外边距双倍问题，且在多数场景下更可靠地参与高度计算 -
clear: both的作用是强制这个伪元素落到所有浮动子元素下方，形成一个可视的“底部位置” - 如果父容器本身也设了
float或position: absolute，那它自己已经脱离文档流，加clearfix也没用——必须作用在直接包裹浮动子项的那个父容器上
现代项目里最该警惕的其实是还在用 float 做布局
如果你正新建页面、重构模块，或者只是维护一个还能升级的项目，优先替换掉 float 布局。Flex 和 Grid 天然不脱离文档流，父容器高度自动包含子项，clearfix、overflow: hidden、flow-root 全都不需要。
-
display: flex在 IE10+ 已稳定；display: grid在 Chrome 64+/Firefox 58+/Safari 15.4+ 支持良好 - 老项目兜底时，
clearfix要补*zoom: 1（IE6–7）和单冒号写法（:after），否则不生效 - 最容易被忽略的是：清除浮动必须加在“直接包裹浮动子元素”的那个父容器上，隔一层就断链，查起来极难定位
真正复杂的地方从来不是怎么写清除代码，而是判断哪个容器该清除、它是不是已经被上层浮动或定位污染了——得一层层往上 inspect，而不是堆 clear: both。
