CSS中overflow:hidden为什么可以清除浮动

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 还没效果

常见失效原因不是写错了，而是被其他样式覆盖或干扰：

1. display: flex 或 display: grid 的父容器上设 overflow: hidden —— 这两种 display 值本身不参与 BFC 触发逻辑
2. 父元素有 transform、filter、will-change 等属性，创建了新层叠上下文，BFC 失效（尤其 Safari 中 transform: translateZ(0) 就够让这个方案翻车）
3. CSS 优先级问题：overflow: visible 或 auto 被更高权重样式覆盖，computed 值实际不是 hidden
4. 父元素设置了 height 或 max-height，强行压住高度，掩盖了 BFC 的作用

overflow:hidden 的副作用比你想象中更常踩坑

它本质是裁剪，不是布局修复，所以溢出内容会被静默截断：

1. position: absolute 的下拉菜单、Tooltip、气泡提示，一旦超出父容器边界就消失
2. 移动端在该容器内做 touchmove 滚动，可能卡顿或完全失效
3. 配合 transform: scale() 或 clip-path 时，裁剪边界仍按原始尺寸计算，导致误切
4. IE6/7 下还可能引发双倍边距或 margin 合并异常（因为触发的是 hasLayout 而非标准 BFC）

现代项目该用什么替代

优先选 display: flow-root：

1. 语义明确：就是“我要创建一个包裹浮动的 BFC”，不附带裁剪行为
2. 无副作用：不影响 position: fixed 定位，不干扰 transform 动画，不隐藏滚动条
3. 浏览器支持已全覆盖（Chrome 64+、Firefox 59+、Safari 15.4+、Edge 79+）
4. 若需兼容 IE，则退回伪元素方案：.clearfix::after { content: ""; display: table; clear: both; }

真正容易被忽略的是：你花时间调 overflow: hidden 的裁剪和失效问题，往往是在维护一条本不该继续走的技术路径 —— 浮动布局本身在 flex/grid 成熟后，已退化为图文环绕等极少数场景的遗留方案。