清除浮动本身不直接触发重排，但常见方式（如clear: both）会引发o(n)回溯扫描，导致整页卡顿；推荐用display: flow-root创建bfc隔离布局，或直接采用flex/grid布局替代。
清除浮动本身不会直接触发重绘或重排，但几乎所有实际清除方式都会间接导致重排（reflow），而重排必然伴随重绘（repaint）——关键在于“谁被重排”和“重排多大范围”。
clear: both 为什么会让整页卡顿
它不自己重排，但强制浏览器回溯检查前面所有浮动兄弟节点的位置，以确认“清除点”在哪。这个过程是 O(n) 的线性扫描，尤其当页面有几十个 float: left + clear: both 的卡片时，每次新增一项或 resize 窗口，浏览器就得从当前元素一路往上翻 DOM 树，重新计算整个浮动上下文的布局边界。
- 常见错误现象：
clear: both放在分页栏、加载更多按钮上，滚动加载新卡片后页面明显“跳一下” - 真实影响范围：不只是当前元素，还可能拉入前 N 个浮动块及其后续文字流、
position: relative后代 - DevTools 验证方法：打开 Rendering 面板 → 勾选 “Layout Shift Regions”，再触发 clear 变化，看高亮区域是否远超预期
::after 伪元素清除法的性能真相
用 .clearfix::after { content: ""; display: block; clear: both; } 确实比加空 <div> 更轻量，但它依然依赖 <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+ 起支持 - 别再写
zoom: 1或*zoom: 1：IE6/7 已淘汰，且该 hack 会干扰 hasLayout 计算，反而增加 layout dirty check 次数
overflow: hidden 清除浮动的隐藏代价
它能触发 BFC，让父容器包裹浮动子项，看起来“清除成功”，但副作用非常具体：任何超出容器的内容（比如下拉菜单、阴影、position: absolute 的提示框）会被裁剪。更隐蔽的是，某些场景下浏览器会因此放弃 layout 缓存，哪怕只是改个 margin，也得重走一遍完整 layout 流程。
- 典型踩坑：
.sidebar { overflow: hidden; }+.tooltip { position: absolute; right: -100px; }→ tooltip 被截断 - 性能影响：比
display: flow-root多一次 overflow 边界检测，且无法与 transform 动画友好共存 - 替代方案：若必须兼容老浏览器，优先用
display: inline-block（需注意默认 baseline 对齐问题）或float自身父级
最常被忽略的一点：清除浮动不是目的，而是为了修复因 float 脱离文档流引发的塌陷。与其花精力优化清除逻辑，不如直接用 display: flex 或 display: grid 替代——它们天然不塌陷、不依赖 clear、layout 可缓存、增量更新粒度细。2026 年了，还在为 clear: both 调优，大概率说明布局模型本身已经过时。
