overflow:hidden清除浮动的本质是触发BFC，使父容器包含浮动子元素高度，并非真正清除浮动；现代应优先使用display:flow-root或clearfix::after方案。
它根本不是“清除”浮动，而是触发了 BFC —— 父容器因此重新包含浮动子元素的高度，看起来像“清掉了”，其实浮动还在。
overflow:hidden 触发 BFC 才是关键
W3C 规范里，overflow 值为 visible 时明确不触发 BFC；而设为 hidden、auto 或 scroll 会强制创建块级格式化上下文（BFC）。BFC 是一个独立渲染区域，它的规则之一就是：容器必须包含所有子元素的盒模型尺寸，包括浮动元素。所以父容器高度不再塌陷，并非“清除了 float”，而是“不得不把 float 的高度算进来”。
这跟 display: flow-root 的原理一致，只是后者专为此设计，前者是副作用。
为什么有时候加了 overflow:hidden 还没效果
常见失效原因不是写错了，而是被其他样式覆盖或干扰：
立即学习“前端免费学习笔记（深入）”；
-
display: flex或display: grid的父容器上设overflow: hidden—— 这两种 display 值本身不参与 BFC 触发逻辑 - 父元素有
transform、filter、will-change等属性，创建了新层叠上下文，BFC 失效（尤其 Safari 中transform: translateZ(0)就够让这个方案翻车） - CSS 优先级问题：
overflow: visible或auto被更高权重样式覆盖，computed 值实际不是hidden - 父元素设置了
height或max-height，强行压住高度，掩盖了 BFC 的作用
overflow:hidden 的副作用比你想象中更常踩坑
它本质是裁剪，不是布局修复，所以溢出内容会被静默截断：
-
position: absolute的下拉菜单、Tooltip、气泡提示，一旦超出父容器边界就消失 - 移动端在该容器内做
touchmove滚动，可能卡顿或完全失效 - 配合
transform: scale()或clip-path时，裁剪边界仍按原始尺寸计算，导致误切 - IE6/7 下还可能引发双倍边距或 margin 合并异常（因为触发的是 hasLayout 而非标准 BFC）
现代项目该用什么替代
优先选 display: flow-root：
- 语义明确：就是“我要创建一个包裹浮动的 BFC”，不附带裁剪行为
- 无副作用：不影响
position: fixed定位，不干扰 transform 动画，不隐藏滚动条 - 浏览器支持已全覆盖（Chrome 64+、Firefox 59+、Safari 15.4+、Edge 79+）
- 若需兼容 IE，则退回伪元素方案：
.clearfix::after { content: ""; display: table; clear: both; }
真正容易被忽略的是：你花时间调 overflow: hidden 的裁剪和失效问题，往往是在维护一条本不该继续走的技术路径 —— 浮动布局本身在 flex/grid 成熟后，已退化为图文环绕等极少数场景的遗留方案。
