Grid嵌套过深会引发布局计算爆炸，3层以上在Android 5.1 WebView中单次getComputedStyle耗时超8ms；应合并为单层Grid、用display:contents或flex替代，并避免滥用will-change。
Grid 嵌套过深会导致布局计算爆炸
移动端 CPU 资源紧张，Grid 的嵌套层级每增加一层，浏览器就要多做一次 grid-template-areas 解析、grid-row/grid-column 位置映射和隐式轨道生成。实测发现：3 层以上 Grid 嵌套在 Android 5.1 WebView 中，单次 getComputedStyle 调用耗时可从 0.2ms 涨到 8ms+，滚动中频繁触发会直接卡顿。
常见错误场景包括：
• 在 .list-item 内部又套一层 display: grid 做图标+文字对齐
• 为每个卡片单独设 grid-template-columns: 1fr max-content，而非统一由外层容器控制列数
• 使用 grid-area + 多层命名区域嵌套，导致解析树深度翻倍
实操建议：
• 把多层 Grid 合并为单层：用 grid-template-areas 描述整体布局，子元素只靠 grid-area 定位，不新建容器
• 替换掉“Grid 套 Grid”的结构，改用 display: contents 让中间层不参与布局（注意兼容性：iOS Safari 15.4+ 支持）
• 真需要局部网格控制时，优先用 flex + gap 替代——Flex 的布局开销比 Grid 低约 40%
will-change 对 Grid 容器几乎没用，别乱加
will-change: transform 对 Grid 容器本身无效。Grid 的重排（reflow）发生在 layout 阶段，而 will-change 只能提前创建合成图层（compositing layer），它不加速 layout 计算。你在 .grid-container 上写 will-change: grid-template-columns，浏览器直接忽略——这个值根本不被任何引擎支持。
立即学习“前端免费学习笔记（深入）”；
真正可能受益的，是 Grid 中**正在被 JS 动态移动的子项**，比如拖拽排序时的 .grid-item。但必须满足两个前提：
• 该子项已用 transform: translate() 实现位移（而非修改 grid-row/grid-column）
• 位移是连续高频的（如手指拖动），不是一次性跳变
实操建议：
• 删除所有作用于 display: grid 容器的 will-change 声明，全局搜索 will-change.*grid 并清理
• 若需拖拽优化，只在 touchstart 时给目标 .grid-item 设置 style.willChange = 'transform'，touchend 后立即设回 'auto'
• 绝对不要写 will-change: contents 或 will-change: scroll-position——前者无实际效果，后者纯属无效语法
替代方案比 will-change 更可控
比起依赖 will-change 这个“预告机制”，直接控制图层生命周期更稳妥。尤其在旧安卓机上，will-change 一旦设了不清理，图层就常驻内存，3 个元素同时挂着就能触发 OOM。
推荐组合：
• 用 transform: translateZ(0) 显式创建合成层（兼容性好，语义明确，不会被误删）
• 配合 contain: layout paint 限制重绘范围——这对 Grid 子项特别有效，能阻止父容器因子项变化而全量重排
• 对虚拟滚动中的 Grid item，用 content-visibility: auto（Chrome 85+/Edge 89+）让离屏项跳过渲染流水线
性能影响要点：
• contain: layout paint 在 iOS Safari 上对 Grid 支持完整，但在 Android 6.0 WebView 中仅部分生效，需降级为 contain: strict
• content-visibility 不兼容 IE 和 UC 浏览器，上线前务必检查用户 UA 分布
• 所有 contain 类属性都要求元素有明确尺寸（height 或 min-height），否则可能塌陷
真要盯住的不是 Grid 写法，而是图层数量
开发者容易陷入“调 Grid 属性”的误区，但移动端卡顿的根因往往是图层失控。一个 Grid 容器里若有 12 个 .grid-item，每个都带 will-change: transform，旧安卓机就会分配 12 个独立 GPU 图层，加上滚动容器自身图层，轻松突破 20MB 内存阈值。
验证方式很简单：真机连接 Chrome DevTools → Rendering 面板 → 勾选 “Layer borders” 和 “FPS meter”。滑动页面时看绿色边框是否密集闪烁，FPS 是否稳定在 58–60。若图层边框不消失、FPS 掉到 30 以下，说明图层没被回收——这时候再回去查 JS 有没有漏掉 el.style.willChange = 'auto'，比反复调整 grid-gap 数值管用得多。
