浮动元素不参与文档流，导致非浮动元素背景叠于其下，非因z-index而是布局层叠逻辑不同；clear仅对文档流中块级元素有效；overflow:hidden触发bfc但有裁剪等副作用；flow-root是现代解法但需兼容处理。
浮动元素不是“无法覆盖”非浮动元素，而是它根本不会去“覆盖”——它和非浮动元素压根不在同一个布局层叠逻辑里。所谓“覆盖”，其实是你看到的视觉重叠，本质是文档流断裂后，非浮动元素的背景、边框、块级盒模型位置错乱造成的假象。
为什么非浮动元素的背景会跑到浮动元素下面
非浮动块级元素（比如 <div>、<code><p></p>）仍按正常文档流计算位置，但它的父容器若没被撑高，自身高度可能为 0px；而浮动元素已脱离流，不参与父容器高度计算。结果就是：非浮动元素的盒模型“从顶部开始画”，但因为父容器没高度，它实际渲染起点和浮动元素重合，背景色就叠在浮动元素背后了。
- 这不是 z-index 问题，
z-index对纯浮动元素无效（除非额外加position: relative） - 文字内容能绕开浮动，是因为内联格式化上下文（IFC）天然支持环绕；但块级盒模型没有这种智能，只认“我在哪行开始”
- 用开发者工具检查该非浮动元素的
computed height，大概率是0px或远小于预期
clear: both 为什么有时像“没起作用”
clear: both 只对块级、仍在文档流中的元素生效，且必须加在“受干扰的那个非浮动元素”上——不是加在浮动元素自己身上，也不是加在父容器上。
- 如果目标元素是
display: inline或display: inline-block，clear直接忽略 - 如果浮动方向是
float: right，但你只写clear: left，它不会下移 - 如果该元素本身有
margin-top: -20px这类负边距，clear会被抵消，看起来像失效 - 响应式断点中，浮动可能被媒体查询取消，但
clear没同步移除，导致多出空白
overflow: hidden 触发 BFC 的真实代价
给非浮动元素加 overflow: hidden 确实能立刻让它避开浮动区域，因为它触发了 BFC，强制创建独立格式化上下文。但这不是“修复”，是“隔离”。
- 绝对定位子元素（如 tooltip、dropdown）一旦超出该元素边界，就会被裁剪，且无警告
- 如果该元素内部用了
transform: translateX(100px)把内容拉出，同样被截断 - 老安卓 WebView（Android 4.4）或某些 iOS Safari 版本中，
overflow: hidden+transform组合可能引发重绘异常 - 更隐蔽的问题：
overflow: hidden会让scrollIntoView()行为失效，因为滚动目标被判定为“不可见”
display: flow-root 是现代解法，但别盲目替换
display: flow-root 是专为这类问题设计的，它触发 BFC 且不干预溢出，语义清晰。但它不是万能补丁。
- IE 完全不支持，旧版 Android WebView（≤4.4）也不认；必须用
@supports (display: flow-root) {}做降级 - 如果非浮动元素原本是
display: inline-block，加flow-root后它变成块级，宽度会收缩到内容尺寸，需手动补width: 100% - 混用
float和flow-root在同一元素上（如float: left; display: flow-root）会导致行为不可预测，后者会覆盖前者 - 真正该警惕的，是还在用
float做整体布局——flex或grid下，这些“覆盖”“塌陷”“clear 失效”问题根本不会出现
