overflow: hidden能“包住”浮动元素是因为它触发BFC，使父容器重新计算高度并包含浮动子元素；但会裁剪溢出内容，如绝对定位菜单、阴影等，且在Flex/Grid容器中失效。
overflow: hidden 为什么能“包住”浮动元素
它不是真正清除浮动，而是触发 BFC（块级格式化上下文），让父容器重新计算高度，把浮动子元素的高度纳入自身尺寸。只要父元素是块级、且 overflow 值不是 visible（比如设为 hidden、auto 或 scroll），就会生效。
但副作用很实在：overflow: hidden 会裁剪所有超出边界的视觉内容——包括 position: absolute 的下拉菜单、box-shadow、负 margin 拉出的图片边缘、甚至 transform 位移的部分。移动端还可能干扰 touch-action 行为。
-
overflow: auto比hidden稍友好：只在真溢出时显示滚动条，但同样会裁剪 - 该技巧在
display: flex或display: grid容器里完全失效——因为浮动在这些上下文中本就不参与布局流 - IE6/7 对
overflow: hidden触发 BFC 的支持不稳定，慎用于老项目
clearfix 是什么，怎么写才真正生效
它靠伪元素插入一个“清道夫”，用 clear: both 把浮动撑下来，不依赖 BFC，也不影响溢出渲染。现代写法必须满足三个条件：
-
::after伪元素要设content: ""（空字符串也行，但不能省略） -
display必须是block或table（inline-block不触发清除） -
clear: both才能挡住左右浮动，仅left或right不够
标准写法：
立即学习“前端免费学习笔记（深入）”；
.clearfix::after {
content: "";
display: table;
clear: both;
}
如果父容器本身已是 display: flex 或 display: grid，加 clearfix 没意义——浮动自动退化，高度自然包裹。
display: flow-root 是不是万能解
它是专为解决这个问题设计的，语义清晰、无裁剪副作用、代码干净。但不是所有场景都适用：
- Chrome 64+、Firefox 59+、Safari 15.4+ 支持良好；IE 完全不支持
- 它创建新 BFC，但不会像
overflow: hidden那样强制裁剪，也不会像clearfix那样插入 DOM 节点 - 如果父容器需要滚动（比如弹窗内容区），
flow-root不自带滚动控制，得额外加overflow: auto
简单说：新项目、无需兼容 IE，优先用 display: flow-root；旧项目维护或需兼容性，clearfix 更稳妥。
浮动到底还该不该用
浮动本就不是为布局设计的，只是历史惯性沿用至今。很多所谓“清除浮动”的需求，其实是没意识到更现代的替代方案：
- 两栏/多栏自适应？
display: flex+flex: 1控制分配，比浮动 + 清除稳定得多 - 网格类布局？
display: grid配合fr单位，响应式更可控 - 图文环绕？
float还有存在价值，但纯布局场景中，删掉float改用inline-block或flex往往更稳
真正容易被忽略的点是：遇到浮动溢出，第一反应不该是“怎么清”，而是“这里非得用浮动吗”。重构成本有时远低于打补丁成本。
