clear: both 触发 O(n) 回溯扫描而非重排，display: flow-root 无扫描、无副作用，是现代项目最优解；overflow: hidden 虽撑高父容器但可能引发定位上下文重置。
用 DevTools 的 Layout Shift Regions 直接观察回溯扫描范围
clear: both 不是重排，而是触发 O(n) 回溯扫描——浏览器要从当前元素往前逐个检查浮动兄弟节点的位置，才能确定“清除点”在哪。这个过程在滚动加载、窗口 resize 或 JS 动态插入新卡片时特别明显。
打开 Chrome DevTools → Rendering 面板 → 勾选 Layout Shift Regions，然后触发一次 clear 变化（比如点击按钮插入一个带 clear: both 的分页栏），看高亮区域是否远超预期：如果连前面 5 个浮动卡片和后续文字流都被染色，说明影响面过大。
-
clear: both在::after伪元素里照样触发回溯扫描，不是“用了伪元素就变轻量” -
overflow: hidden不触发回溯，但它强制创建 BFC 的同时会裁剪内容，副作用更隐蔽 -
display: flow-root完全不走 clear 语义，也不扫描 DOM，高亮区域只锁死在容器内
避免在 flex/grid 容器里测试 clearfix 性能
浮动在 display: flex 或 display: grid 上下文中被忽略，clear 属性直接失效。此时加 clearfix 类不仅没用，还会干扰渲染链路——浏览器仍要解析伪元素、生成匿名盒、执行无意义的 clear 计算。
- 给
display: flex父容器加clearfix，DevTools 的 Layout 检查会显示“clearignored” - 现代项目中，如果子项用了
float，说明布局模型已经混用，性能问题根源不在清除方式，而在结构本身 - 真要测性能，得确保父容器是
display: block或display: inline-block，且子元素确实在用float
对比时重点看 JS 动态操作后的帧率抖动
静态页面看不出差别，真正拖慢体验的是交互场景下的布局响应。比如点击“加载更多”后插入一组浮动卡片，再加一个 clear: both 的分隔符，这时观察 FPS 曲线。
立即学习“前端免费学习笔记（深入）”；
-
clear: both方案常伴随 200–400ms 卡顿，尤其在低端 Android WebView 中 -
display: flow-root容器下，插入浮动子项后父高度自动撑开，无额外 layout 触发，FPS 更平稳 -
overflow: hidden虽然也撑高父容器，但若子项含position: absolute向外偏移，可能意外重置定位上下文，引发 layout thrashing
别忽略兼容性补丁带来的隐性开销
为兼容 IE6–IE7 写的 zoom: 1 + ::after 组合，看似只是多一行 CSS，实则引入了两层额外负担：IE 的 hasLayout 触发机制本身就有性能代价；而 display: table（老式 clearfix 常用）会创建匿名表格盒，干扰 margin 合并，拉长样式计算链。
- 现代项目若已放弃 IE 支持，
display: flow-root是唯一无需补丁、无副作用、且浏览器原生优化的方案 - 仍需兼容 IE 的项目，优先用
zoom: 1+::after { content: ""; display: block; clear: both; }，避免display: table - 所有方案在父容器设了
overflow: hidden或auto时都会失效——BFC 已提前闭合，clear失去作用对象
clear 是旧模型的补丁逻辑，flow-root 是新模型的原生能力——两者底层行为完全不同，不能只比代码行数。** 
