Grid卡顿主因是频繁重排重绘而非Grid本身慢；应慎用will-change，仅对高频独立变化项临时加transform；改用CSS变量+calc()更新列宽；大量增删时优先用display: contents隐藏；性能分析紧盯Layout中的Grid track sizing和Paint中的Grid overlay。
Grid布局卡顿但控制台没报错，先看will-change有没有乱用
动态Grid（比如拖拽调整列宽、实时增删grid-item）卡顿，90%不是Grid本身慢，而是浏览器反复重排重绘时被逼着做昂贵的合成层提升。很多人一上来就加will-change: transform或will-change: grid-area，结果反而让图层管理更混乱，内存涨、掉帧更明显。
真正该做的：只对「持续高频变化且独立于其他元素」的子项加will-change，而且必须配合transform动画——Grid自身属性（如grid-column、grid-template-columns）改了不会触发GPU加速，will-change对它们基本无效。
- ✅ 正确做法：拖拽中给当前移动的
item临时加style="will-change: transform;"，松手立刻移除 - ❌ 错误做法：给整个
.grid-container设will-change: grid-template-columns——这会让浏览器以为整个网格要动，强制升层，但实际变的只是CSS变量值 - ⚠️ 注意：
will-change不能写在CSS里长期生效，否则图层驻留导致内存泄漏
grid-template-columns用fr单位 + JS频繁更新时的性能陷阱
用grid-template-columns: 1fr 2fr 1fr配合JS实时计算列宽很常见，但每次改style.gridTemplateColumns都会触发同步布局计算（Layout Thrashing），尤其当容器父级有复杂flex嵌套或resizeObserver监听时，卡顿指数级上升。
根本问题在于：浏览器必须立刻测量所有子项尺寸来分配fr空间，而JS改完样式后如果紧接着读offsetWidth之类，就会强制同步回流。
立即学习“前端免费学习笔记（深入）”；
- ✅ 改用CSS自定义属性 +
calc()：把比例抽成--col1: 1; --col2: 2;，模板写成style="grid-template-columns: calc(var(--col1) * 1fr) calc(var(--col2) * 1fr) 1fr"，JS只改CSS变量，不碰grid-template-columns本身 - ✅ 批量更新：用
requestAnimationFrame节流，把多次列宽变更合并到单帧内完成 - ⚠️ 避免在
scroll或mousemove里直接改grid-template-columns字符串——哪怕只改一个数字，也是全量解析+重布局
大量grid-item动态增删时，display: contents比visibility: hidden更省命
想“隐藏但保留Grid位置”？别用visibility: hidden。它会让元素继续参与Grid轨道计算，浏览器仍要为它预留空间、计算行高列宽、甚至触发grid-auto-rows逻辑，数据量大时开销惊人。
display: contents才是正解：它让元素从渲染树消失，但子节点（如果有）仍按原位置参与Grid布局——前提是这些子节点本身是Grid item或能被Grid容器直接管理。
- ✅ 适用场景：列表项包裹一层
<div class="item-wrapper"><div class="grid-item">...</div></div>，隐藏时给.item-wrapper加display: contents，.grid-item继续受Grid控制 - ❌ 不适用场景：item本身就是
<div class="grid-item">，再加<code>display: contents会把它彻底踢出Grid上下文，位置丢失 - ⚠️ 兼容性注意：IE完全不支持，Edge 16+才支持；若需兼容，退化方案只能用
position: absolute; left: -9999px模拟“视觉隐藏”，但得手动维护grid-area避免布局塌陷 - ✅
Layout事件里出现“Grid track sizing”或“Grid placement”——说明浏览器正在反复计算轨道和项目位置，根源通常是JS改了grid-template-*或grid-area，或者子项尺寸不稳定（比如图片没设宽高） - ✅
Paint事件里出现“Grid overlay”或大量小块Grid cell绘制——大概率是用了background或border画Grid线，而不是用grid-gap或伪元素，导致每个单元格单独绘制 - ⚠️ 容易忽略：Timeline里
Recalculate Style时间长，往往是因为Grid容器上有复杂CSS选择器（如.container > div:nth-child(odd)），每次增删item都要重算全部样式
Chrome DevTools里定位Grid性能瓶颈，盯死Layout和Paint两栏的“Grid”关键词
打开Performance面板录制操作，别只看FPS曲线。点开每一帧的详细耗时，重点找两类标记：
Grid的性能问题从来不在“多复杂”，而在“改得有多勤、改得有多懵”。越想靠CSS自动算，越要小心JS伸手去掰它的计算过程——那根手指动一下，整个网格就得重新呼吸一次。
