Grid嵌套超2层会导致布局计算爆炸，Android 5.1 WebView中单次getComputedStyle耗时达8ms+并引发掉帧；根本原因是每层新增display: grid都会触发隐式轨道生成、grid-template-areas解析及行列映射，3层后形成循环依赖与多轮重排。
Grid嵌套超过2层，性能就不是“变慢”，而是“失控”——Android 5.1 WebView中单次getComputedStyle耗时可飙到8ms+，滚动直接掉帧。这不是写法不优雅的问题，是浏览器布局引擎被反复拖进重排深坑。
为什么三层Grid嵌套会让layout阶段爆炸
每多一层display: grid，浏览器就要多做一次隐式轨道生成、grid-template-areas解析、以及子项grid-row/grid-column映射。当嵌套达3层，且中间层用了minmax(min-content, 1fr)或auto，就会触发多轮layout计算（DevTools Rendering tab里能看到重复“Layout”事件）。
- 常见雷区：卡片内部再套Grid对齐图标+文字、每个列表项自己定义
grid-template-columns、用grid-area层层命名嵌套区域 - 真实瓶颈不在DOM节点数，而在浏览器必须为每个子网格向上回溯父容器尺寸——而父容器尺寸又依赖子内容，形成循环依赖链
- esbuild处理10层SCSS嵌套时，可能生成10万种选择器组合，直接OOM
用display: contents代替无意义的Grid包裹层
很多“嵌套Grid”其实只是为了视觉对齐，而非语义分组。用display: contents让父元素退出盒模型，子元素直接受外层Grid约束，既保留结构语义，又砍掉一层布局开销。
- 兼容注意：
display: contents在iOS Safari 15.4+、Chrome 65+、Firefox 63+支持；旧版需fallback为visibility: hidden+position: absolute占位 - 不能用于表单控件（如
input、button），它们会失去可访问性 - 比删DOM更安全：DOM结构不变，JS仍能通过
parentElement正常遍历
把“Grid套Grid”转成单层Grid + subgrid或grid-template-areas
真正需要语义隔离的场景（比如仪表盘中每张卡片内部有标题/操作按钮），别新建Grid容器，改用subgrid复用外层轨道，或用grid-template-areas预定义整体结构。
立即学习“前端免费学习笔记（深入）”；
-
subgrid写法：.card { display: grid; grid-template-rows: subgrid; }，前提是父容器已设grid-template-rows且自身display: grid - 兼容fallback：外层用
grid-template-areas: "header main" "footer footer"，卡片内加display: contents，让.card__title等子元素直接响应外层区域线 - 绝对避免在
:hover或@keyframes里变更grid-template-columns——这会强制同步重排整个容器
动态Grid场景下，禁用will-change但启用contain
will-change: transform对Grid容器完全无效，浏览器直接忽略；但它对正在拖拽的.grid-item有效——前提是你用transform: translate()移动它，而不是改grid-row。
- 必须配对使用：
touchstart时设style.willChange = 'transform'，touchend后立刻设回'auto' - 更稳的方案是给每个复杂子项加
contain: layout style paint，明确隔离渲染边界（Chrome 52+/Firefox 69+/Safari 15.4+） - Grid容器自身没设
height或max-height，是卡顿最常被忽略的起点——子项撑开后持续触发布局，问题从这里蔓延
真正难的不是写出嵌套Grid，而是判断哪一层“看起来需要嵌套”实则只是CSS习惯性冗余。浏览器不关心你的设计稿分了几层，它只按规则逐层算轨道——少一层，就少一次不可预测的重排。
