清除浮动本身不重排页面，但 clear: both 会触发 O(n) 回溯扫描，导致滚动或 resize 时卡顿；推荐用 display: flow-root 创建 BFC 隔离布局影响，避免回溯与裁剪问题。
清除浮动本身不重排页面，但 clear: both 会触发 O(n) 回溯扫描，滚动或 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，让父容器包裹浮动子项，看起来“清除成功”，但副作用非常具体：
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- 任何超出容器的内容（比如下拉菜单、阴影、
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 - 一旦用了 flex/grid，就该彻底放弃
float布局逻辑，而不是补clearfix
真正影响性能的从来不是“有没有清除”，而是“怎么清除”——回溯扫描、BFC 边界重算、溢出裁剪检测，这些细节在高频交互中会迅速暴露出来。别只盯着 DOM 结构干净与否，先看 layout 计算路径是否可控。
