真正有效的解法是加虚拟滚动，如react-window或IntersectionObserver，只挂载可视区域±2行项；避免全量DOM渲染、动态改grid-template-columns、visibility:hidden等引发重排的写法。
大量 grid-item 卡顿，先确认是不是虚拟滚动缺失
Grid 本身不卡，卡的是全量 DOM 渲染。用 display: grid + repeat() 渲染上千项？本质仍是同步创建并挂载所有 grid-item，浏览器要 layout、paint、composite 全流程走一遍——和用 flex 或 div 堆没区别。
真正有效的解法不是调 Grid 参数，而是加虚拟滚动（virtual scroller）。比如 react-window 或原生 IntersectionObserver + scrollHeight 计算可视区域，只挂载当前屏内 ±2 行的项。
- 别指望
content-visibility: auto在 Grid 直接子项上起效——Flex/Grid 容器里它常失效或错位 -
contain-intrinsic-size必须写在每个grid-item上，且不能是0或空值；横向长表可设contain-intrinsic-size: 800px 0（高度由内容撑开） - 若用 Magic-Grid 这类 JS 库，动态内容必须配
items: N预估总数，否则会反复重排
频繁更新 grid-template-columns 导致 Layout Thrashing
每次改 style.gridTemplateColumns 字符串，浏览器都得重新解析、测量所有子项、分配 fr 空间——尤其父容器有 flex 嵌套或监听 resize 时，卡顿指数级上升。
正确做法是抽离比例为 CSS 变量，JS 只改变量值：
立即学习“前端免费学习笔记（深入）”；
/* CSS */
.grid-container {
grid-template-columns: calc(var(--col1) * 1fr) calc(var(--col2) * 1fr) 1fr;
}
- JS 中只执行
el.style.setProperty('--col1', '2')，不碰gridTemplateColumns - 批量变更用
requestAnimationFrame节流，合并到单帧 - 绝对避免在
scroll或mousemove回调里直接拼字符串赋值
动态增删 grid-item 时，display: contents 比 visibility: hidden 更省命
visibility: hidden 的坑在于：元素仍参与 Grid 轨道计算，浏览器照旧预留空间、算行高列宽、触发 grid-auto-rows —— 数据量大时开销惊人。
- 用
display: contents让元素“消失”且彻底退出布局流，父容器不再为其生成盒模型 - 配合
grid-column/grid-row数值定位更可控，比依赖grid-area字符串命名更轻量 - 若需保留占位，优先用
margin或min-height显式撑开，而非靠隐式轨道
嵌套 Grid 或 min-content 是隐式重排链的温床
嵌套 ≥3 层 + 中间层用 min-content 或 auto？Chrome DevTools 的 Rendering tab 里会看到重复 “Layout” 事件——这是浏览器被迫多轮测量导致的隐式重排链。
- 父容器显式设
width/height，切断子网格反向影响父尺寸的路径 - 用
contain: layout paint（Chrome 85+ / Firefox 90+）隔离中间层渲染边界 - 多数“需要嵌套”的场景，其实可用
subgrid或display: contents拉平结构，避免套娃 -
grid-template-areas在 >100 项时解析开销明显，动态生成优先用数值定位grid-column: 2 / 4
性能瓶颈从来不在 Grid 语法本身，而在你让浏览器反复猜尺寸、反复重排、反复升合成层。盯紧 DevTools 的 Layout 和 Paint 阶段耗时，比调参数更重要。
