overflow:auto 不清除浮动，而是通过触发BFC使父容器包含浮动元素从而撑高；但易误判溢出致滚动条异常，推荐用display:flow-root替代。
overflow:auto 本身不“清除”浮动，只是触发 BFC 导致高度重算
它根本没在清除 float —— float 依然生效，子元素照样脱离文档流。真正起作用的是：设置 overflow: auto 会让父元素生成一个新的 BFC（块级格式化上下文），而 BFC 的规范行为之一是「包含内部所有浮动元素的边界」，于是父元素高度被撑开。这看起来像“清除了浮动”，实则是 BFC 的副作用。
但这个副作用会带来一个关键问题：BFC 容器在计算是否溢出时，依赖的是「内容盒的实际占据范围」，而浮动元素不参与父容器的高度计算逻辑，导致浏览器对“是否溢出”的判断容易失准。
为什么滚动条会莫名其妙出现？
常见诱因不是内容真超出了宽高，而是渲染引擎误判了溢出。以下情况极易触发：
-
position: absolute或transform: translateY(-20px)的子元素，可能被当成“向上溢出”，从而激活垂直滚动条 - Flex 容器里混用
float，子项无视float，但overflow: auto触发的 BFC 仍试图包裹——结果高度计算混乱，判定溢出失败 - 父容器设了
max-height，但浮动子元素实际占据高度远超该值（因塌陷未被识别），浏览器就认为“内容撑爆了”，强制显示滚动条 - iOS Safari 旧版本中，
overflow: auto对line-height或字体度量计算有偏差，造成微小高度溢出，滚动条闪现
display: flow-root 是更干净的替代方案
display: flow-root 是专为解决这个问题设计的，语义明确、无副作用：
立即学习“前端免费学习笔记（深入）”；
- 它创建 BFC，能正确包含浮动子元素，让父容器高度恢复
- 它不改变溢出行为：
overflow值保持原样，不会凭空加滚动条 - 它不会裁剪
position: absolute、box-shadow或top: -10px的 tooltip - 现代浏览器支持良好（Chrome 58+ / Firefox 57+ / Safari 10.1+）
如果必须兼容 IE 或极老 Android WebView，才考虑伪元素 ::after { content: ""; display: table; clear: both; } 方案。
给父容器加 overflow:auto 前，务必确认三件事
否则大概率踩坑：
- 父容器是否设置了
height或max-height？没有的话，overflow: auto永远不会触发滚动条，也谈不上“误显” - 子元素有没有用
position: absolute或负margin？这些元素不参与高度计算，却可能被 BFC 容器当作溢出内容裁剪或误判 - 是否真的需要滚动？如果只是为了“撑开高度”，
display: flow-root或clear: both更安全；如果确实要滚动，请把overflow-y: auto下移到具体可滚动的子容器上，而不是整个浮动父级
最常被忽略的一点：你加 overflow: auto 的那个元素，它的 display 值必须是 block 或 inline-block，而不是 flex 或 grid —— 后两者本身不靠浮动布局，加了也没用。
