display: flow-root是更干净的解法，它专为创建无副作用bfc设计，语义清晰、不裁剪溢出内容、无需额外html，现代浏览器支持稳定。
父容器高度塌陷不是“没清浮动”这么简单，而是浮动元素彻底脱离文档流，导致父容器在布局计算阶段就直接忽略它们——height: auto、min-height、甚至display: block都救不回来。
为什么clear: both本身不撑开父容器
clear: both只对应用它的那个元素生效，让它避开所有浮动，但它不会让父容器“重新包含”浮动子项。常见错误写法是给浮动子元素自己加clear: both，这毫无意义；或者把clear: both写在父容器上，CSS根本不认这个声明。
- 必须把
clear: both加在一个**位于所有浮动子元素之后**的块级元素上（比如空<div>） <li>这个元素得是父容器的**直系子元素**，且不能被<code>display: none或visibility: hidden隐藏 - 它只是把自己下推到浮动结束位置，父容器的高度仍是靠它撑出来的，而非真正“感知”到浮动子项
- HTML里多一个无语义节点，维护时容易被误删或遗漏
-
overflow: hidden兼容性好（IE6+），但副作用明显：任何超出父边界的子内容（如position: absolute下拉菜单、tooltip、阴影、动画移出）都会被裁剪 -
overflow: auto在Safari里可能无故出现空白滚动条，尤其当子元素有微小负margin时 - 如果父容器本身就需要溢出表现（比如卡片hover浮层、弹窗锚点），这个方案等于自废一臂
- 它不解决语义问题——代码里看不出“此处需容纳浮动”，后期接手的人可能随手删掉
- 它明确表达意图：
flow-root= “我要建一个包含浮动的新格式化上下文”，语义清晰 - 完全不影响溢出行为：子元素该弹出就弹出，该滚动就滚动，不会被意外裁剪
- 无需伪元素、无需额外类名、无需空标签，纯CSS一行解决
- 现代浏览器支持已稳定：Chrome 64+、Firefox 59+、Safari 15.4+、Edge 79+；如果你的项目不需支持 Safari
- 父容器用了
display: flow-root，但某个子元素又写了position: absolute——绝对定位仍会脱离BFC，父容器还是算不到它高度 - 响应式断点里，
float被媒体查询关掉，但clearfix类没同步移除，可能引发意外换行 - Safari 15.3 及更早版本对
display: flow-root有渲染异常，比如内联元素换行错位，真机测试前别只信桌面模拟器 - 某些UI库（如旧版Bootstrap）的栅格类内部依赖
float，强行套flow-root可能导致列宽计算错误
用overflow: hidden触发BFC为什么能生效
它通过强制父容器生成一个新的块级格式化上下文（BFC），而BFC的规则之一就是：**容器必须包含其内部所有浮动子元素的高度**。这不是“清除”，是布局模型层面的重新包含。
为什么display: flow-root是更干净的解法
这是CSS专门设计用来创建无副作用BFC的值，2018年写入标准，目的就是替代overflow: hidden这类“借副作用办事”的 hack。
真正容易被忽略的边界情况
很多问题不是出在“有没有清浮动”，而是浮动和其他脱离文档流的属性混用：
