overflow:hidden并非真正清除浮动，而是触发bfc使父容器包裹浮动子元素并撑开高度，但浮动元素仍脱离文档流，后续内容继续绕行，且可能裁剪下拉菜单、tooltip等溢出内容。
直接给父容器加 overflow: hidden 能让高度恢复、背景显示，但不是“清除浮动”，而是触发 BFC 实现包裹 + 裁剪；它不解决后续元素绕行问题，还可能意外截断下拉菜单或 tooltip。
为什么 overflow: hidden 看似有效却不是真正清除浮动
浮动元素仍脱离文档流，overflow: hidden 只是让父容器创建 BFC，从而“包含”浮动子元素并撑开自身高度。但浮动本身没被清除——紧挨着父容器的下一个 <div> 里的文字，依然会从浮动块右侧开始排版。
<ul>
<li>常见错误现象：<code>overflow: hidden 加了，父容器背景和边框回来了，但后续普通流内容还是绕着浮动元素走
clear: both 或伪元素清除，比如 .clearfix::after
浮动图片 max-width: 100% 失效的根本原因
浮动图片的 max-width: 100% 常常无效，不是 CSS 写错了，而是它的“包含块”大概率不是你写的那个父容器，而是视口或更上层定位祖先。没有明确的宽度参照系，100% 就无从算起。
- 必须同时满足：父容器有显式宽度（如
width: 100%或固定值）+ 创建 BFC（推荐display: flow-root） -
overflow: hidden虽能触发 BFC，但会裁剪 box-shadow、旋转标签、绝对定位气泡等延伸内容 - 现代替代方案：直接用
display: flex，图片设flex: 0 0 auto+max-width: 100%，天然受父容器约束，无需 float
绝对定位子元素突破 overflow: hidden 的真实原因
overflow: hidden 对 position: absolute 子元素默认无效——因为它只裁剪属于该容器“包含块”的内容，而绝对定位元素的包含块由最近的已定位祖先决定，不是父容器本身。
- 关键动作：父容器必须同时设
position: relative和overflow: hidden - 漏掉
position: relative，绝对定位子元素就往上找定位上下文，最终相对于视口定位，必然溢出 - 若结构不可改（比如第三方组件嵌套），可用
transform: translateZ(0)强制父容器成为层叠上下文和裁剪容器，但注意可能触发额外合成层，影响滚动性能
最易被忽略的一点：BFC 不是魔法开关，它只管自己容器内的流与浮动关系；外部元素是否绕行、绝对定位是否被裁剪，全取决于你有没有同时控制好定位上下文、尺寸约束和层叠上下文这三件事。
