浮动嵌套每多一层，浏览器需多次重排，因clear: both会逐层回溯浮动元素位置触发同步重排；三层嵌套至少三次BFC创建或清除，display: flow-root是更优替代方案。
浮动嵌套每多一层，浏览器就要多一次重排回溯
浮动本身不慢，但嵌套后清除逻辑会触发反复重排。浏览器遇到 clear: both 时，必须回溯前面所有浮动元素的位置来确定“清除点”，这个过程打断渲染流水线、强制同步重排（reflow）。嵌套越深，浮动容器层级越多，每个父容器都可能需要独立清除——而每次清除都不是孤立事件，它会让浏览器重新计算整条浮动链的几何位置。
常见错误现象：resize 窗口或 :hover 触发时明显卡顿；DevTools 的 Rendering 面板中 Layout 时间持续高于 16ms；滚动列表里浮动卡片频繁闪烁。
- 三层浮动嵌套（如
.card → .card-body → .tag-list）时，至少要触发三次独立 BFC 创建或清除操作 - 每层父容器若未显式触发 BFC（如没加
display: flow-root或伪元素 clearfix），就会塌陷为height: 0，导致后续布局错乱，JS 获取offsetHeight等属性时又触发强制同步 layout - Android 5.1 WebView 中，单次
getComputedStyle调用在深层浮动结构下耗时可达 8ms+，直接拖垮帧率
clear: both 不是“清一次就完事”，而是逐层收口的累加负担
clear 的作用范围仅限于当前元素与**同级浮动元素**的关系，它不会向上穿透影响祖父容器。这意味着：嵌套 3 层浮动容器，就得在 3 个不同层级分别处理清除或 BFC，不能靠顶层一个 .clearfix 解决全部问题。
容易踩的坑：
立即学习“前端免费学习笔记（深入）”；
- 只给最外层
.page加::after清除，中间层.sidebar仍塌陷，背景色/边框消失 - 误用
overflow: hidden在某中间层——它虽能触发 BFC，但会意外裁剪position: absolute子元素（如下拉菜单、tooltip） - 在循环生成的 item 上重复写
clear: both，而不是统一由父容器用display: flow-root承担包裹责任
display: flow-root 是比 clearfix 更轻量的替代方案
display: flow-root 创建一个新的块级格式化上下文（BFC），天然包含内部浮动子元素，无需清除逻辑，也不参与盒模型计算。它比伪元素 ::after + clear: both 更干净，也比 overflow: hidden 更安全（不裁剪溢出内容）。
兼容性已覆盖主流环境（Chrome 64+、Firefox 58+、Safari 15.4+、Edge 79+），IE 完全不支持——如果必须兼容 IE11，才退回到 clearfix。
- 写法极简：
div.container { display: flow-root; } - 注意它会重置 margin-collapse，相邻块级元素外边距不再合并
- 别对表单控件（
<input>、<button></button>）设display: contents来“优化”浮动，会破坏可访问性
浮动嵌套真正难优化的不是写法，而是 DOM 关系不可预测
浮动只影响**直接父容器**，不向上冒泡。这意味着：哪怕你把 HTML 结构写得再扁平，只要 CSS 里用了多层浮动 + 多层清除，浏览器就必须在 layout 阶段反复确认每一层的尺寸依赖关系——而这些关系在 JS 动态插入、删除节点时极易断裂。
现代项目中，浮动仅剩两个不可替代场景：float: left 实现图文环绕，以及某些无法重构的老系统侧边栏。其余横向布局一律优先用 display: flex 或 display: grid，它们天然规避了清除和塌陷问题，且 layout 计算路径更可控。
最容易被忽略的一点：性能瓶颈往往不出现在“写了什么”，而出现在“改了什么”。一次 classList.add('is-active') 触发样式重算时，深层浮动结构会让浏览器多跑好几轮 layout 回溯——而这部分开销，在初始渲染时根本看不出来。
