别用 float 做布局，现代项目应迁移到 flex 或 grid，老项目可用 flow-root 替代 clear: both；float 多了会因频繁重排导致卡顿，clear: both 是性能放大器而非解决方案。
直接结论：别用 float 做布局，尤其是多层嵌套或高频交互场景；现代项目应立即迁移到 display: flex 或 display: grid，老项目兜底用 display: flow-root 替代 clear: both。
为什么 float 多了就卡？不是渲染慢，是重排停不下来
浮动元素脱离文档流后，浏览器必须在每次 DOM 变更、窗口 resize、甚至 :hover 伪类触发时，反复确认它的边界、文字环绕范围、后续兄弟元素的定位起点——这些计算无法缓存，且每次都要从头扫一遍浮动链。
常见错误现象包括：
-
DevTools > Rendering > Layout Shift Regions高频闪烁，单次 Layout 耗时持续 >16ms - 滚动加载新卡片时，每加一个
clear: both就整块重排一次 - 三层浮动嵌套（如
.card → .card-header → .tag）下，getComputedStyle调用耗时飙升至 8ms+（Android 5.1 WebView 实测）
clear: both 是性能放大器，不是解决方案
clear: both 本身不消耗资源，但它强制浏览器回溯所有同级浮动元素来确定“清除点”，时间复杂度是 O(n)。它只作用于当前元素与**同级浮动兄弟**的关系，不会穿透到父级——这意味着嵌套越深，你得在每一层都手动处理清除，而不是靠顶层一个 .clearfix 一劳永逸。
容易踩的坑：
- 把
clear: both写在浮动子元素上（如div.item { float: left; clear: both; }），完全无效 - 在循环生成的列表项里重复加
clear: both，导致新增一项就重排全部 - 用
overflow: hidden触发 BFC，却意外裁剪了position: absolute的下拉菜单或 tooltip
替换方案怎么选？看兼容性和使用场景
迁移不是一刀切，要按实际环境选最轻量的替代：
- 新项目或 Chrome 64+/Firefox 59+/Safari 15.4+ 环境：直接用
display: flow-root包裹浮动容器，写法极简 ——.container { display: flow-root; }，不裁剪、不塌陷、无副作用 - 需兼容 IE11：fallback 到伪元素
.clearfix::after，但必须用display: table（不是block），否则不触发 BFC：.clearfix::after { content: ""; display: table; clear: both; } - 横向排列需求（如导航栏、卡片流）：用
display: flex; flex-wrap: wrap;，宽度固定 + 自动换行，彻底告别float: left和clear - 网格类布局（如响应式相册、侧边栏+主内容）：用
display: grid; grid-template-columns: repeat(auto-fill, minmax(300px, 1fr))，无需清除逻辑，计算可缓存
动画和滚动区域里，float 必须零容忍
给 float 元素加 transform: translateX() 不会提升为合成层，因为它的渲染上下文仍绑在主文档流里，结果是动画帧全靠主线程 layout + paint 完成，极易掉帧。
正确做法：
- 侧边栏滑入：移除
float，改用position: sticky或flex布局，再加transform - 图文环绕仅保留
img单独float: left，其他内容保持标准流，缩小影响范围 - 高频交互区域（如搜索建议、实时消息流）禁止任何
float，一律用flex或grid+will-change: transform（且动画结束立刻 JS 清除）
真正难处理的不是“怎么清除浮动”，而是历史代码里那些隐式依赖浮动位置的 JS 逻辑（比如基于 offsetTop 计算弹层位置）——这类地方必须同步重构，否则换完 CSS 也会出视觉错位。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
