flex居中本身不慢，但align-items: stretch会触发多轮布局计算，尤其在嵌套或含图片/文本时引发连锁重排；应改用align-items: center或align-self: center，或确保父容器有明确高度。
Flex 实现居中本身不拖慢性能，但写法不当会触发多轮布局计算，尤其在滚动、动画或低端设备上容易卡顿。
justify-content + align-items 居中为什么有时变慢
默认 align-items: stretch 是罪魁祸首：它会让每个子项拉伸并重新测量内容高度。如果子项里有图片、iframe 或未设高的块级元素，浏览器就得反复重排 —— 这不是“居中”本身慢，而是 stretch 强制同步测量导致的连锁反应。
- 典型场景：
.card { display: flex; flex-direction: column; }里放了<img>，又没设height或aspect-ratio - 更糟的是嵌套：父容器 stretch → 子项内容重测 → 子项内再 flex → 再 stretch → 再重测……三层以上就可能单帧 Layout 超 16ms
- 解决办法不是禁用居中，而是显式关掉 stretch：
align-items: center或给子项加align-self: center
flex 居中对渲染通路的实际开销
Flex 布局走的是 multi-pass 渲染路径，而普通 block 是 single-pass。但这只是理论差异 —— 现代浏览器（Chrome 120+、Safari 17+）对 display: flex; justify-content: center; align-items: center 这种组合做了深度优化，只要满足两个条件：父容器有明确高度（如 height: 100vh），且子项不含动态尺寸内容，它和 display: block 的帧耗基本一致。
- 真正要警惕的是“动态高度 + stretch”组合：比如用
min-height: fit-content配合文字流变化，每次 DOM 更新都触发 Layout Thrashing -
margin: auto在 flex 容器里也能居中，但它绕过 stretch，只走一次 layout，比align-items: center更轻量（前提是子项是块级且非弹性） - 别为了“语义正确”硬套 flex 居中：单个元素居中，
position: absolute; inset: 0; margin: auto;在多数场景下反而更快
Chrome DevTools 里怎么确认是不是 flex 居中拖慢了
打开 Performance 面板 → 录制一次滚动或 resize 操作 → 看 Bottom-Up 树里有没有高频出现的 FlexLayoutAlgorithm 或 NGFlexLayoutAlgorithm 调用；同时检查 Recalculate Style 时间占比是否异常高，且大量 align-items、justify-content 属性被标记为 “dirty”。
- 快速验证：临时把容器
display: flex改成display: block，再测帧率 —— 如果从 45fps 回升到 58fps，说明 flex 计算确实是瓶颈 - 注意 iOS Safari 14 及更早版本对 stretch 的处理特别低效，下拉刷新后可能直接卡死，必须显式设
align-items: center - 不要只看“用了 flex”，要看“用了哪些 flex 属性”：
justify-content几乎无开销，align-items: stretch才是隐藏成本大户
最常被忽略的一点：居中效果是否真的需要 flex？很多所谓“flex 居中”场景，其实只是因为父容器没设高度才失效 —— 补上 min-height: 100vh 后，align-items: center 就立刻变快，而不是去删 flex。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
