Grid布局本身不触发GPU加速，真正触发的是子项的transform、opacity或will-change等属性；需避免left/top动画引发重排，确保子项具备独立合成层并解决容器尺寸塌陷问题。
Grid容器本身不触发GPU加速
Grid布局（display: grid）不是GPU加速的触发条件。浏览器不会因为用了grid-template-rows或grid-area就自动创建合成层——它只是布局算法，不涉及图层提升。真正触发GPU加速的是后续在Grid子项上做的动画属性，比如transform、opacity或will-change。
Grid子项动画卡顿，大概率是没脱离文档流
常见错误是直接对Grid子项用left、top或margin做过渡：
.item { transition: left 0.3s; }
.item:hover { left: 100px; }
这会强制每帧触发重排（reflow），CPU全程扛着跑。正确做法是改用transform: translateX(100px)——但前提是该子项已具备独立合成层基础。否则即使写了transform，浏览器也可能因“无变化预期”而延迟提升图层。
- 加
will-change: transform可提前提示，但仅限高频动画元素，滥用反而增加内存开销 - 更稳妥的是加
transform: translateZ(0)（或translate3d(0,0,0)），强制创建合成层 - 注意：如果Grid容器自身高度塌陷（比如父级Flex没给交叉轴约束），子项的
transform可能视觉无效——先解决尺寸问题，再谈加速
嵌套Grid + Flex时，合成层容易被“压扁”
当Grid容器放在Flex父级中，且Flex项未设置align-items: stretch（或父Flex容器本身无高度），Grid容器计算出的高度可能是0px。此时即便子项写了transform，浏览器也难为其分配独立纹理空间——合成层创建失败，GPU加速自然落空。
立即学习“前端免费学习笔记（深入）”；
验证方式很简单：Computed面板里看该子项的layer是否被标记为“Composited”，而不是“Painted”。没标上，说明还在主线程里画。
- 临时加
min-height: 1px或height: 1px到Grid容器，观察是否突然变流畅——这是判断尺寸塌陷最直接的信号 - 避免在Grid容器上同时用
grid-template-rows: 1fr和height: auto，fr单位需要明确的高度上下文才能解析 - Chrome DevTools 的
Layers面板比Elements更能暴露问题：点开后找对应元素，看它是否出现在独立图层树里
filter 或 opacity 动画在Grid中表现异常的根源
filter和opacity确实能触发GPU加速，但在Grid布局中容易出现“闪烁”或“错位”，尤其当Grid轨道动态变化（比如grid-auto-rows: minmax(0, 1fr)）时。这是因为滤镜/透明度变化依赖图层快照，而Grid的隐式轨道重算可能造成图层重建不同步。
解决方案不是禁用这些属性，而是切断动画与布局变更的耦合：
- 把要加
filter的元素用position: absolute或transform: translateZ(0)从Grid流中抽离 - 避免在
:hover时同时修改grid-column和filter——拆成两个独立状态切换 - 移动端尤其要注意：
backface-visibility: hidden有时比opacity更稳，因它强制图层独立且不参与混合计算
transform变成“纸上谈兵”。 
