浮动元素触发重排的典型场景是从该元素所在行向上回溯到最近块级容器并重排整个子树，诱因包括尺寸样式变化、父容器resize、内容增长及强制布局读取；clear属性会扩大重排范围，现代方案如Flex/Grid性能更优且可控。
浮动元素触发重排的典型场景
只要浮动元素的尺寸、位置或父容器尺寸发生变化，浏览器就必须重新计算所有浮动元素的布局位置——这不是局部更新，而是从浮动元素所在行开始向上回溯到最近的块级容器，重新执行整个子树的布局。常见诱因包括：
- width、height、margin、padding 动态修改
- 父容器 resize（比如响应式侧边栏展开）
- 浮动元素内部文本内容增长（如加载更多评论后高度增加）
- 使用 getComputedStyle 或 offsetHeight 强制同步读取布局信息，紧接着修改样式
clear属性让重排范围扩大一倍
clear 本身不触发重排，但它会强制浏览器“确认前面所有浮动是否已结束”，导致布局引擎必须回溯检查更早的浮动兄弟节点。尤其当页面中存在多个 float: left + clear: both 的卡片流时，每个 clear 都可能拉入前 N 个浮动块参与重排。
- 避免在循环渲染中为每个项加 clear: both，改用伪元素清除（::after { content: ""; display: table; clear: both; }）
- 如果必须用 clear，优先选 clear: left 或 clear: right，而非 clear: both
- 在 Flex/Grid 已可用的场景下，clear 几乎没有正当理由继续使用
浮动导致的重绘不可控区域
浮动元素脱离文档流后，其后续非浮动兄弟元素的定位依赖于浮动占位，一旦浮动元素重排，不仅自身要重绘，还可能连带重绘它“推下去”的文字流、行内替换元素（如 <img alt="CSS浮动布局的重排与重绘_性能角度看浮动布局的开销" >）、甚至 position: relative 的后代——因为它们的 containing block 可能被浮动间接影响。
- 不要对浮动容器内的 transform 元素做频繁动画，它不会避免重绘，反而可能因层叠上下文变化引发额外合成层切换
- 避免在浮动元素上设置 border-radius + box-shadow，圆角和阴影会显著增加重绘像素量
- 检查 DevTools 的 Rendering 面板，开启 “Paint flashing”，真实观察哪些区域被反复重绘
现代替代方案的性能对比底线
Flex 和 Grid 不仅语义清晰，关键是在浏览器底层做了大量优化：它们的布局计算可缓存、增量更新粒度更细、且不依赖全局浮动上下文。实测中，同等复杂卡片列表：
- 浮动布局在窗口 resize 时平均触发 3–5 次完整重排
- Flex 布局通常只有 1 次，且只重排容器内直接子项
- Grid 布局在列数固定时，resize 甚至可跳过重排，仅调整 track 尺寸
- 所有现代方案都支持 contain: layout paint 主动隔离，而浮动无法被该 CSS 属性有效控制
浮动不是不能用，但只要涉及动态内容、响应式行为或滚动中更新，它的重排开销就很难预测——尤其是当它和 JavaScript 布局读写混用时，那个“看不见的回溯链”最容易被忽略。
