清除浮动本身性能开销小，但错误用法如clear: both会触发o(n)回溯扫描，导致滚动或resize时卡顿；推荐用display: flow-root创建bfc隔离布局影响。
清除浮动本身几乎不消耗性能，但错误的写法会拖慢布局计算，尤其在滚动加载或窗口 resize 时明显卡顿。
clear: both 触发的是回溯扫描，不是重排
浏览器看到 clear: both，不会立刻重排整个页面，但它必须从当前元素开始，向上遍历 DOM 树，逐个检查前面所有浮动兄弟节点的位置，才能确定“清除点”在哪。这个过程是 O(n) 线性扫描，不是常数时间。
- 常见错误现象：
clear: both被加在分页栏、load-more按钮上，每次插入新卡片后页面“跳一下” - 真实影响范围：不只是当前元素，还可能拉入前 N 个浮动块 + 后续文字流 +
position: relative后代的 layout 边界重新计算 - DevTools 验证方法：打开 Rendering 面板 → 勾选 “Layout Shift Regions”，再触发 clear 变化，看高亮区域是否远超预期
::after 伪元素清除法真没开销？别信
.clearfix::after { content: ""; display: block; clear: both; } 确实比加空 <div> 少一个 DOM 节点，但它依然依赖 <code>clear 语义，所以同样触发回溯扫描。
- 真正让它变快的，是配合
display: flow-root或overflow: hidden主动创建 BFC，把重排锁死在容器内 - 推荐写法：
.clearfix { display: flow-root; }—— 不需要伪元素，也不依赖clear，现代浏览器直接隔离布局影响 - 兼容性注意：
display: flow-root在 Safari 10.1+ / Chrome 58+ / Firefox 53+ 支持；IE 完全不支持，Edge 16+ 起支持
overflow: hidden 清除浮动的隐藏代价最常被忽略
它能触发 BFC，让父容器包裹浮动子项，看起来“清除成功”，但副作用非常具体：
- 任何超出容器的内容（比如下拉菜单、阴影、
position: absolute的提示框）会被裁剪 - 某些场景下浏览器会因此放弃 layout 缓存，哪怕只是改个
margin，也得重走一遍完整 layout 流程 - 典型踩坑：
.sidebar { overflow: hidden; }+.tooltip { position: absolute; right: -100px; }→tooltip被截断 - 性能影响：比
display: flow-root多一次 overflow 边界检测，且无法与transform动画友好共存
flex/grid 容器里加 clearfix 是无效且危险的
浮动在 display: flex 或 display: grid 上下文中已被忽略，clear 属性根本不起作用。
- 常见错误现象：给一个
display: flex的父容器也加clearfix，结果子元素依然浮动、父容器依旧塌陷 - 使用场景限制：仅适用于传统文档流布局，即父容器是
block或inline-block，且子元素确实在用float - 参数差异：
::after必须设content: ""，否则伪元素不生成；必须设display: table或block，否则clear无效 - 现代替代：优先用
display: flow-root，它一行代码解决，且不污染 HTML 结构
真正影响性能的是布局结构混用，不是清除方式本身。比如在同一个模块里同时用 float、flex 和 position: absolute，浏览器就得反复切换 layout 上下文——这种混乱比多写一个 ::after 严重得多。
