clear: both 会导致页面卡顿，因其触发 O(n) 回溯扫描而非重排，影响范围包括前 N 个浮动块、后续文字流及 relative 后代的 layout 边界；推荐用 display: flow-root 创建 BFC 规避该问题。
会，但影响不来自“清除”动作本身，而来自你选的清除方式触发的浏览器底层行为。
clear: both 为什么会让页面卡顿
它不直接重排，但强制浏览器做 O(n) 回溯扫描：从当前元素开始，逐个检查前面所有浮动兄弟节点的位置，才能确定“清除点”在哪。这个过程在滚动加载、窗口 resize 或动态插入新卡片时特别明显。
- 常见错误现象：
clear: both被加在分页栏、load-more按钮上，每次插入新卡片后页面“跳一下” - 真实影响范围不止当前元素——可能拉入前 N 个浮动块 + 后续文字流 +
position: relative后代的 layout 边界重新计算 - DevTools 验证方法：打开 Rendering 面板 → 勾选 “Layout Shift Regions”，再触发
clear变化，看高亮区域是否远超预期
伪元素 clearfix 真的更轻量吗
比空 <div> 少一个 DOM 节点，但 .clearfix::after { content: ""; display: block; clear: both; } 依然依赖 clear 语义，所以同样触发回溯扫描。
- 必须设
content: ""，否则伪元素不生成 - 必须设
display: block或display: table，否则clear无效 - 在
display: flex或display: grid容器里加clearfix是无效的——浮动被忽略，clear不起作用
display: flow-root 是现代最优解吗
是，但它不是万能兼容方案。
立即学习“前端免费学习笔记（深入）”；
-
display: flow-root主动创建 BFC，不依赖clear，不扫描 DOM，把重排锁死在容器内 - 不会裁剪
position: absolute元素、不影响box-shadow渲染、不干扰position: fixed参照系 - 兼容性：Safari 10.1+ / Chrome 58+ / Firefox 53+ 支持；IE 完全不支持，Edge 16+ 起支持
- 若需兼容 IE，可用
zoom: 1（仅 IE）+::after组合，但要注意伪元素默认是inline，必须显式设display: table
真正拖慢页面的，从来不是“要不要清除浮动”，而是“用什么方式让浏览器算布局”。clear 是旧模型的补丁，flow-root 是新模型的原生能力——别在 flex 容器里还写 clearfix，也别为兼容 IE 而在现代项目里硬塞 overflow: hidden，后者裁剪内容、破坏动画、干扰层叠上下文，问题比它解决的更多。
