overflow:hidden 并非真正清除浮动，而是通过触发BFC使父容器包含浮动子元素高度并裁剪溢出内容；其失效场景包括flex/grid布局、transform等创建层叠上下文、computed值为visible、或设定了height/max-height；现代项目应优先使用display:flow-root、伪元素清除法或直接弃用float。
它根本不能“清除”浮动——float 依然存在，子元素仍脱离文档流；overflow: hidden 只是触发了 BFC，让父容器重新包含浮动子元素的高度，同时把所有溢出内容无声裁掉。
为什么 overflow:hidden 看起来像清除了浮动
浏览器渲染时，只要父容器满足三个条件：display 是块级（如 block）、overflow 计算值为 hidden/auto/scroll、且不是根元素（），就会强制创建一个 BFC。BFC 容器必须独立计算内部尺寸，于是把浮动子元素的边界纳入高度计算——父容器“突然有高了”，后面元素不再上移，视觉上就像“清掉了”。
这不是修复浮动，而是绕过它：你没动 float，只是给父容器加了个“结界”，让它自己把浮动框包进去。
哪些情况下 overflow:hidden 根本不生效
常见失效场景远比想象中多，别只盯着语法写对没写对：
-
display: flex或display: grid的父容器上加overflow: hidden—— 这两种 display 值本身不走 BFC 流程，加了也白加 - 父元素有
transform、filter或will-change—— 它们会创建新的层叠上下文，干扰 BFC 触发，尤其在 Safari 中极不稳定 -
overflow: hidden被更高优先级规则覆盖，最终 computed 值其实是visible——visible是 W3C 明确禁止触发 BFC 的唯一值 - 父元素设了
height或max-height—— 高度被硬性截断，BFC 虽然触发了，但“撑高”效果被压制，误以为失效
overflow:hidden 清浮动的真实代价
它不是解决方案，是副作用妥协。只要父容器内有以下任一情况，就可能出问题：
-
position: absolute或position: fixed子元素（如下拉菜单、Tooltip）超出父边界 → 被无声裁切，连 debug 都难定位 - 移动端
touchmove在该容器内滚动卡顿或失效 —— BFC 裁剪区域会干扰事件捕获路径 - 配合
transform: scale(0.95)等缩放时，裁剪边界仍按原始尺寸计算，导致内容被意外切掉 - 动画中父容器高度动态变化，
overflow: hidden可能掩盖重排失败或视觉错位，因为裁剪是静态边界的
现代项目该用什么替代
如果你真需要“包裹浮动子元素”，优先选语义明确、无副作用的方案：
-
display: flow-root—— 专为创建无裁剪 BFC 设计，Chrome 64+、Firefox 59+、Safari 15.4+、Edge 79+ 全支持，写法就是一行：display: flow-root - 伪元素
::after清除法 —— 兼容 IE9+，稳定可靠：.clearfix::after { content: ""; display: table; clear: both; } - 直接弃用
float布局 —— 除非做图文环绕，否则display: flex或display: grid天然包含子项高度，“清除浮动”这个概念在它们内部根本不存在
最容易被忽略的一点：你花时间调 overflow: hidden 的裁剪边界和 touchmove 行为，其实是在维护一个本不该存在的技术路径。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
