grid子元素缩放连带重绘整行，是因为未启用gpu合成层，导致浏览器将整个grid子树视为共享绘制层；添加transform-gpu（如translatez(0)）可创建独立合成层，使动画仅限自身区域，避免污染兄弟元素。
为什么Grid子元素缩放会连带重绘整行
Chrome中对grid容器里的<img>加scale过渡，常导致后续所有兄弟项一起重绘——不是动画逻辑写错了，而是默认没启用GPU合成层。position: relative还会额外创建层叠上下文，让绘制边界失控。
解决方法很简单：给动画元素加transform-gpu（即transform: translateZ(0)或will-change: transform），让它成为独立合成层。这样缩放只影响自身像素区域，不会“污染”相邻项。
- 别在父容器上加
will-change: grid-template-columns——它无效，还拖慢内存 - 如果必须用
z-index提层，优先移除position: relative，改用transform位移替代 - 测试时打开 Chrome DevTools → Layers 面板，确认动画期间只新建1个图层，而非每帧都爆增
哪些Grid属性根本不能加transition
grid-column、grid-row、grid-template-columns这些属性不支持平滑过渡。浏览器无法对2 / 4这种离散值做插值，强行加transition只会让布局突变+反复重排。
真正可动画的只有视觉层属性：transform、opacity、filter。它们走合成通道，不触发Layout。
- 要实现“网格位置切换”，用
order+transition: order 0.2s，它只改绘制顺序，不重算轨道 - 要响应式切列数，别用JS改
style.gridTemplateColumns，改用预设class或repeat(auto-fit, minmax()) - 若必须JS控制，缓存计算结果，resize时用
debounce，只在宽度跨越阈值时才更新
嵌套Grid为何越深越卡
三层及以上display: grid嵌套（比如grid → grid → grid）会让浏览器反复解析轨道尺寸。尤其当DOM动态更新时，一次子项变化可能触发父、祖父两层同步重排。
DevTools Layers面板里如果看到某区域频繁重建「Composite Layers」，基本就是嵌套过深+内容尺寸不稳定共同导致的。
- 卡片列表场景下，别为每张卡片再套一层
grid——卡片内部用flex或普通流式布局 - 外层用
grid-template-areas划分区域，卡片内用display: contents消除盒模型，让子元素直接受外层网格线约束 - 中间层网格容器务必加
contain: layout paint（Chrome 85+支持），明确隔离渲染边界
动态增删Grid项时最省命的做法
用visibility: hidden隐藏Grid项？错。它仍参与轨道计算，浏览器照旧预留空间、算行高、跑grid-auto-rows逻辑，数据量一大就卡死。
真正轻量的是display: contents：元素从渲染树中完全消失，但子节点保留并直接受父Grid约束——相当于“隐身但不卸载”。
- 批量增删时，用
DocumentFragment拼DOM，再一次性append，避免逐个appendChild触发多次layout - 大量数据列表，必须配合虚拟滚动：只渲染可视区±2行，其余用
height固定的占位<div>撑开滚动高度 <li>慎用<code>min-content作为轨道基准，改用minmax(0, 1fr)或固定值，切断内容反向影响尺寸的链路
关键点其实就一个：Grid本身不卡，卡的是你让它反复做本不必做的事。最常被忽略的起点，是Grid容器自己没设
height或max-height——子项一撑开，就持续触发布局。
