真正有效的解法是加虚拟滚动+渲染隔离，而非调grid-template-columns；auto-fit+minmax()在大数据量下会触发隐式重排链，导致Layout→Paint阶段卡顿白屏。
Grid 本身不慢，慢的是你让它同步渲染上千个真实 DOM 节点——真正有效的解法不是调 grid-template-columns，而是加虚拟滚动 + 渲染隔离。
为什么直接用 repeat(auto-fit, minmax()) 渲染 1000+ 项会白屏
浏览器不是卡在 Grid 计算上，而是卡在 Layout → Paint 阶段无法完成：每次 resize 或内容变化，它都要为“理论上最多能放几列”预建轨道槽位，哪怕只显示 2 个子项，也要反复测量、分配、回填。DevTools 的 Rendering tab 里会出现连续几十次 “Layout” 事件，页面长时间空白。
-
auto-fit+minmax()在大数据量下本质是隐式重排链触发器，尤其配合grid-auto-rows: minmax(100vh, auto)时，每新增一个子项都可能重算整行 - 父容器没设
height或max-height？子项撑开后持续触发布局，卡顿从这里开始，而不是 Grid 写法本身 - 用了
grid-auto-flow: dense？它强制浏览器反复回填空隙，布局开销指数级上升
必须加 contain: layout paint style，但只加在真实子项上
这个组合值不是“加了就快”，它只在满足三个条件时生效：作用于每个 grid-item 元素（不是容器）、元素有明确边界（比如 width/height 或 min-width）、现代浏览器支持（Chrome 85+/Firefox 90+/Safari 15.4+）。
- 如果用 IntersectionObserver 做虚拟滚动，
contain必须加在“真实挂载的卡片”上，而不是占位用的空div；否则浏览器仍为占位元素保留样式计算上下文 -
contain-intrinsic-size: 280px 160px要写在每个子项上，且不能是0或空值；横向长表可设contain-intrinsic-size: 800px 0（高度由内容撑开） - 旧版 Safari 不支持完整 containment，可降级为
will-change: transform，但别滥用——它会让浏览器为每个项分配独立图层，内存不降反升
动态改列数时，别拼字符串赋值 gridTemplateColumns
每次执行 el.style.gridTemplateColumns = '2fr 1fr'，浏览器都得重新解析字符串、测量所有子项、分配 fr 空间——尤其父容器有 flex 嵌套或监听 resize 时，就是典型的 layout thrashing。
立即学习“前端免费学习笔记（深入）”；
- 正确做法是抽离比例为 CSS 变量：
.grid-container { grid-template-columns: calc(var(--col1) * 1fr) calc(var(--col2) * 1fr); } - JS 中只调
el.style.setProperty('--col1', '2')，不碰gridTemplateColumns字符串 - 批量变更必须用
requestAnimationFrame节流，合并到单帧；绝对避免在scroll或mousemove回调里直接赋值
虚拟滚动里，display: contents 比 visibility: hidden 更省命
visibility: hidden 的坑在于：元素仍参与 Grid 轨道计算，浏览器照旧预留空间、算行高列宽、触发 grid-auto-rows——数据量大时开销惊人。
-
display: contents让元素“消失”且彻底退出布局流，父容器不再为其生成盒模型 - 配合
grid-column/grid-row数值定位更可控，比依赖grid-area字符串命名更轻量 - 若需保留占位，优先用
margin或min-height显式撑开，而非靠隐式轨道
最容易被忽略的点：Grid 容器自身没设 height 或 max-height，导致子项撑开后持续触发布局；还有就是以为加了 contain 就万事大吉，却忘了它必须作用于每个真实渲染的子项，且要配明确尺寸——否则浏览器直接忽略。
