Flex容器设display: flex不一定高效，因计算成本高，易触发重排；关键在合理使用：避免滚动/动画中读写布局属性、减少嵌套、优先固定尺寸、慎用flex: 1、用transform替代影响布局的属性。
Flex容器设了display: flex就一定高效吗？
不一定。浏览器对flex的计算成本比block或inline高得多，尤其当子项数量多、嵌套深、或存在动态尺寸依赖时，容易触发频繁重排（reflow）。关键不在“用了没”，而在“怎么用”。
常见错误现象：resize事件中反复修改flex-basis或width；父容器宽高未固定却让子项用flex: 1撑满；在scroll回调里调用getBoundingClientRect()再改order。
- 避免在滚动/动画帧中读写布局属性（如
offsetWidth、clientHeight），这会强制同步重排 - 若子项尺寸可预知，优先用固定值（如
flex: 0 0 200px）而非flex: 1，减少弹性算法参与 - 不要用
flex-direction: column+height: 100%模拟“等高列”，改用min-height或aspect-ratio更轻量
嵌套Flex为什么会让渲染变慢？
每层display: flex都会增加一层布局树遍历和弹性系数求解。三层以上嵌套时，Chrome DevTools 的 Layout 阶段耗时可能翻倍，尤其在低端设备上明显卡顿。
使用场景：常见于“页头+主内容+页脚”外再套一层“左右分栏”，而左右分栏内部又各自用flex做按钮对齐——实际只需最外层flex控制整体流向，内层用margin或text-align就够了。
立即学习“前端免费学习笔记（深入）”；
- 能用
margin: auto居中的，别用justify-content: center套一层容器 - 按钮组对齐优先用
gap+display: inline-flex，而不是每个按钮都包div再设flex - 表格类布局（如表单字段+提示文字）改用
display: grid，grid-template-columns: max-content 1fr比双层flex稳定得多
flex: 1和flex: auto性能差别大吗？
差别很大。flex: 1等价于flex: 1 1 0，意味着基准尺寸为0，所有空间都靠分配；flex: auto等价于flex: 1 1 auto，会先按内容尺寸测量，再伸缩——后者多一次内容宽度计算，但避免了“从零开始撑开”的不稳定行为。
参数差异：flex: 0 0 auto（不伸缩、不收缩、按内容）最快；flex: 1最慢但最“省心”；中间态如flex: 1 1 min-content是折中选择。
- 列表项宽度需自适应时，用
flex: 1 1 max-content比flex: 1更稳，且避免文字换行抖动 - 图标+文字组合，图标用
flex: 0 0 24px，文字用flex: 1 1 0，比全用flex: 1少一次文本度量 - 绝对定位元素不要放在
flex容器里做“占位”，它仍参与弹性计算；改用position: absolute配合transform脱离文档流
哪些CSS属性会悄悄触发Flex重排？
不是只有width或height才危险。font-size、padding、border-width甚至visibility: hidden（注意不是display: none）都可能让浏览器重新跑一遍弹性布局算法。
性能影响：一次font-size变更，若子项含flex: 1，可能引发整条flex行重算；padding变化则影响flex-basis的基准值，导致分配比例偏移。
- 动画中需要缩放/位移，优先用
transform: scale()或translateX()，它们走合成层，不触发布局 - 隐藏内容用
opacity: 0; pointer-events: none代替visibility: hidden，前者不影响flex计算 - 动态切换主题时，避免批量改
color以外的尺寸相关变量；把font-size等挂到:root并用clamp()控制范围，比JS反复设style.fontSize安全
Flex性能问题往往藏在“看起来没问题”的地方：比如一个flex: 1的卡片容器，里面只有一张图，但图加载后触发img.naturalWidth读取，又顺手改了flex-basis——这一来一回，就足够让60fps掉到30fps。盯住那些“顺便读布局、顺便改样式”的链式操作，比优化单个属性更重要。
