Grid布局本身不卡顿，真正拖慢渲染的是不当写法：如auto-fit/minmax动态计算、多层嵌套、大量grid-area命名、calc()定位及未用contain隔离渲染边界，导致layout耗时从3ms飙升至14ms+。
Grid 布局本身不会拖慢渲染，但写法不当会显著增加 layout 计算耗时——尤其在移动端或动态内容场景下，错误用法可能让单次 layout 从 3ms 涨到 14ms+。
Grid 的 layout 耗时比 Flex 高 15–30%，但不是“不能用”
实测显示，在 Pixel 4a（Android 13）上渲染 20 项卡片列表：
-
Flex（flex-direction: column）：layout 耗时 ~3.2ms -
Grid（grid-template-columns: 1fr; grid-auto-rows: auto）：~4.8ms -
Grid+repeat(auto-fit, minmax(120px, 1fr))：~9.7ms -
Grid嵌套两层（外层grid-cols-1，内层每项再grid-cols-3）：~14.1ms
关键点在于：Grid 的二维约束解算（行+列联动）天然比 Flex 的一维伸缩多一轮计算。但它不卡顿的前提是——你没触发隐式重排链。
哪些写法会让 Grid 突然变慢？
以下操作在低端安卓机或 iOS 14–15 上容易引发长任务（>50ms）：
立即学习“前端免费学习笔记（深入）”；
-
grid-template-columns: repeat(auto-fit, minmax(200px, 1fr))：每次容器尺寸变化都要重解所有列宽 + 多次minmax求值 - 大量使用
grid-area配合命名区域（如 10+ 个grid-area: header / sidebar / main）：字符串映射解析开销线性增长 - 三层以上
display: grid嵌套：Chrome DevTools 中 Layout 耗时常翻倍 - 用
grid-row-start: calc(2n + 1)这类含calc()的显式定位：每次计算都需重新解析 CSSOM
真正卡顿往往不出现在写 Grid 的时候，而出现在你给一个已经由 Grid 定位好的元素又加了 margin——它会破坏原生 gap 行为，触发额外 layout。
contain: layout paint 是移动端 Grid 的硬性优化项
这个属性能切断网格容器与外部布局树的耦合，把 layout 计算限制在局部。实测中，加了 contain: layout paint 的 Grid 容器，Layout 时间可从 ~9.7ms 压至 ~5.5ms（前提是子项无跨格依赖）。
- 必须设在 Grid 容器上，不是子项
- Chrome 85+、Firefox 90+ 支持；Safari 目前仍不支持
contain: layout - 若同时用了
grid-template-areas或大量span，效果会被削弱——因为浏览器仍需全局校验轨道一致性
最容易被忽略的是：性能差距在静态页面里不明显，但一旦涉及 CMS 动态插入区块、微前端频繁挂载卸载、或卡片流滚动加载，Grid 的 layout debt 就会指数级暴露——这时候不是“能不能跑”，而是“每秒多出几次 reflow”。
