flex布局本身无固有性能优势，真正影响性能的是用法：float因频繁触发重排（如尺寸变化、清除逻辑）而低效，flex通过容器统一调度降低布局失控风险，但需正确配置（如设min-width:0、避免混用width/flex-basis）并规避ie兼容陷阱。
Flex 布局本身没有“性能优势”这一说法——它不比 float 快，也不更省 CPU；真正影响性能的是你怎么用、怎么写、怎么避免重排重绘。浏览器渲染时，float 和 flex 的底层开销差异微乎其微，但错误的 float 用法会高频触发重排，而 flex 在合理配置下能显著降低布局失控风险。
float 触发重排的典型场景
浮动元素位置变化（比如 JS 修改 width 或插入新节点）会强制父容器及后续兄弟元素重新计算流式布局，尤其当浮动项嵌套多层或含长文本时，浏览器需反复测量行高、换行点和清除逻辑。
-
float: left+width: 50%在小屏媒体查询中改为float: none，常因 margin/border 计算误差导致最后一项掉行，触发整行重排 - 用
::after { clear: both }清除浮动时，若伪元素含display: table，可能创建匿名表格盒，干扰 margin 合并，间接拉长样式计算链 - 浮动容器内含
position: absolute子项（如弹窗），一旦父容器高度塌陷后又被overflow: hidden修复，绝对定位坐标系可能意外重置，引发 layout thrashing
flex 避免重排的关键控制点
Flex 不是靠“更快”胜出，而是靠把布局决策收归容器层，减少子项对全局流的影响。但前提是显式关闭某些默认行为。
- 必须加
flex-wrap: wrap：否则默认nowrap，子项宁可溢出也不折行，小屏下直接触发横向滚动+重排 - 含长文本或图片的 flex 项要设
min-width: 0：防止内部内容撑宽容器，导致父级宽度重算 - 图标/头像类固定尺寸项，显式写
flex-shrink: 0：否则在空间不足时被压缩，触发字体回流与重绘 - 避免混用
width和flex-basis：两者冲突时flex-basis优先级更高，但浏览器需额外比对，增加样式计算负担
IE10/11 中 flex 的实际性能陷阱
在仍需兼容 IE10/11 的项目里，flex 的“稳定性红利”会被部分抵消，尤其当开发者忽略前缀和 fallback 行为时。
-
flex: 1在 IE11 中必须写成-ms-flex: 1，否则退化为flex: 0 1 auto，子项不伸缩，反而靠 JS 补位，引入额外重排 -
gap在 IE11 完全无效，若用margin模拟，又回到 float 时代的负边距 hack，容易因未重置:last-child导致间隙错乱，调试时反复刷新验证 - 子元素残留
float: left未清零：浏览器先执行 float 排列再套 flex，结果不可控，常需强制force reflow（如读取offsetHeight）才能让布局就位
真正影响性能的从来不是 flex 或 float 的关键字本身，而是你是否意识到：float 要求每个子项自证存在，flex 要求父容器明确定义规则——漏掉任意一条规则，浏览器就得猜，一猜就慢。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
