Flex 布局在二维场景下性能不如 Grid，并非 Flex 本身慢，而是用错维度：Flex 强行模拟网格会触发 layout thrashing、重排频繁、嵌套过深；Grid 则通过声明式轨道、原生 gap 和独立行列控制，减少重复计算与回流。
Flex 布局在某些场景下渲染性能不如 Grid，不是因为 Flex 本身“慢”，而是你用错了地方——当布局本质是二维的，却强行用一维模型去模拟，浏览器反而要做更多补救计算。
用 Flex 模拟网格时触发 layout thrashing
当你写 display: flex + flex-wrap: wrap 来实现卡片墙，并依赖 width 或 flex-basis 控制列数时，浏览器必须反复测量容器宽度、逐个计算子项尺寸、判断换行点、再重新分配交叉轴间距。这个过程在频繁增删节点（比如虚拟滚动或实时搜索）时极易引发 layout thrashing。
- Chrome DevTools 的 Performance 面板里会看到密集的 “Layout” 阶段，尤其在低端 Android 设备上帧率骤降
- Grid 的
grid-template-columns: repeat(auto-fit, minmax(250px, 1fr))是声明式轨道定义，浏览器一次解析就能确定所有列宽，后续内容增减不触发主轴重算 - Flex 下若子项高度不一致，
align-content: stretch会强制重排整行；Grid 中每行高度独立，不影响其他行
Grid 的二维对齐开销被低估
很多人以为 Grid 的二维计算一定更重，但实际在固定结构场景中，它反而减少重复工作：
- Grid 容器一旦建立轨道体系，
justify-items和align-items是统一应用到所有网格项的，无需对每个子项单独计算对齐偏移 - Flex 的
justify-content对单行有效，但多行时要靠align-content，而该属性在子项flex-basis不一致时行为不可预测，常导致回流 - Grid 的
gap是布局层原生属性，不参与子项尺寸计算；Flex 的gap在 Firefox 旧版或 Safari 14.1–16.4 中需退化为margin，间接引入额外重排
嵌套 Flex 层级过深导致样式树膨胀
为实现跨行、固定列宽、等高行等效果，开发者常叠加三层以上 Flex 容器（外层 wrap + 中间 row + 内部 item），这会让 CSSOM 树变深，样式计算和 layout 阶段耗时呈非线性增长。
- 每层 Flex 容器都要维护自己的主轴/交叉轴上下文，父子间
flex-direction切换（如 column → row）会打断继承链，触发额外 layout - Grid 可用
grid-column: span 2直接跨格，无需 wrapper 元素；Flex 要靠position: absolute或 JS 计算，脱离文档流后影响无障碍和打印样式 - 真实项目中，Flex 嵌套超过 3 层，就该考虑抽离为独立 Grid 区域——这不是“升级”，而是回归布局维度本质
真正卡顿的从来不是 display: grid 这行代码，而是把 Grid 当成 Flex 的替代品去写一维逻辑，或者把 Flex 当成 Grid 的廉价替代品去硬凑二维结构。性能差异背后，是浏览器如何翻译你的意图：一维流式模型和二维坐标模型，在渲染管线里的处理路径完全不同。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
