overflow:hidden并非清除浮动，而是通过触发BFC使父容器包含浮动子元素高度；其真实触发条件是：计算后overflow值不为visible、非根元素、display为块级盒类型。
它不是“清除浮动”，而是让父容器重新把浮动子元素的高度算进去——靠的是触发 BFC，不是靠 overflow 本身有清除能力。
overflow:hidden 触发 BFC 的真实条件
很多人以为只要写了 overflow: hidden 就一定触发 BFC，其实必须同时满足三个条件：
- 计算后的
overflow值不为visible（hidden、auto、scroll都行） - 该元素不能是根元素（即不能是
） - 该元素的
display值必须是块级盒类型，比如block、flow-root、table-cell；inline-block可以，但flex或inline不行
常见误判：overflow: hidden 在 display: flex 容器上不会触发 BFC（因为 flex 容器本身已创建了新的格式化上下文，但逻辑不同）；IE6/7 下用 zoom: 1 模拟，但行为不可靠。
为什么 overflow:visible 不行，而 hidden 可以
overflow: visible 是 W3C 明确规定的唯一不触发 BFC 的值。规范要求：只要计算值是 visible，无论是否加 position: relative 或其他样式，都不会创建新 BFC。
立即学习“前端免费学习笔记（深入）”；
而 overflow: hidden 强制浏览器建立独立渲染区域，否则无法判断“哪些内容该被裁掉”——这个裁剪需求，倒逼它启用 BFC。所以它“附带”解决了高度塌陷，但本质仍是裁剪机制的副作用。
实际使用时最常踩的坑
这些不是 bug，是 BFC 裁剪行为的自然结果：
-
position: absolute或position: fixed子元素一旦超出父容器边界，会被无声截断（下拉菜单、Tooltip、Modal 全失效） - 移动端中，
touchmove在该容器内可能被拦截，导致局部无法滑动 - 配合
transform: scale(0.95)时，裁剪框仍按原始尺寸计算，容易误切内容 - 动画中若父容器高度动态变化，
overflow: hidden可能掩盖重排失败或渲染错位，问题更难定位
真正关键的点在于：你写的从来不是“请帮我清浮动”，而是“请把多出来的部分藏起来”。如果项目里还有浮动布局，优先考虑 display: flow-root——它语义明确、无裁剪副作用，且现代浏览器支持已非常稳固。
