Flex布局在多数真实场景下比Float渲染更快，因其主轴计算经浏览器深度优化且重排更少，但需避免滥用flex-wrap、align-items: stretch及漏设min-width: 0；Float因频繁重排和清除浮动开销，在低端设备更易卡顿，仅纯静态图文环绕和超老嵌入式设备中仍具性能优势。
Flex 布局在多数真实场景下比 Float 渲染更快，但优势不来自“更简单”，而来自浏览器对主轴计算的深度优化和更少的重排触发——前提是别乱设 flex-wrap、align-items: stretch 或漏掉 min-width: 0。
Float 触发频繁重排，Flex 只做一次主轴计算
Float 元素一旦插入或尺寸变化，浏览器必须重新计算所有兄弟元素的流式位置：每个浮动块都要判断“左边有没有空位”“右边能不能贴住”“下面文字要不要绕行”，这个过程在低端 Android WebView 或旧版 Safari 中极易卡顿。而 Flex 容器只在子项数量、flex-basis、order 或主轴方向变化时，才执行一次主轴布局（main-axis layout），交叉轴（cross-axis）默认不触发重排。
常见错误现象：
- JS 动态插入一个
float: left元素后，整个父容器卡住 300ms+ - 滚动时修改
opacity的浮动元素，浏览器误判为需持续重排，帧率骤降
Flex 天然 BFC 避免清除浮动开销
Float 必须靠 clear: both、::after { content: ""; display: table; } 或 overflow: hidden 补救高度塌陷，这些方案本身就有性能代价：
立即学习“前端免费学习笔记（深入）”；
-
overflow: hidden在部分 UC 浏览器里会重建裁剪边界，CPU 占用飙升 -
display: table伪元素触发匿名表格盒，干扰 margin 合并，还多占内存 - 多个
.clearfix嵌套时，渲染引擎要反复解析层叠上下文
而 display: flex 容器默认建立 BFC，子项高度自动参与父容器尺寸计算，clear 属性直接被忽略——省掉一行代码，也省掉一次 layout 触发。
低端设备上 Flex 卡顿的三个真凶
不是 Flex 慢，是写法踩了渲染引擎的软肋。以下三处不加约束，低端机立刻掉帧：
- 没写
flex-wrap: wrap却塞入超多子项 → 所有项被强行压在一行，文本撑宽后反复测量换行点 - 留着默认
align-items: stretch，又没设min-height→ 每个子项都要拉伸到最高项高度，长文本反复回流测量 - 容器没加
min-width: 0→ 内部<img>或长单词把容器无限撑宽，触发横向滚动条 + 重绘
这三行保命 CSS 必须手动加上：flex-wrap: wrap、align-items: flex-start、min-width: 0。
Float 唯一还快的两个真实场景
别硬套 Flex，有些地方它真不如 Float 省资源：
- 纯静态图文混排：比如新闻页中
img { float: left; width: 30%; }+ 段落自动环绕——无 JS、无响应式、无动画，Float 渲染路径最短 - 超老嵌入式设备（如国产机顶盒 WebKit 内核），连
display: flex都解析失败，只能靠float + width + margin硬排
真正容易被忽略的是：低端设备的内存比 CPU 更紧张。Flex 每个子项会多持有一个 layout 对象；而 Float 元素定位完成后，后续滚动几乎不触发新 layout——所以卡片流页面若每页 50+ 项，用 float 配合 will-change: transform 有时确实更稳。
