频繁修改 grid-template-columns 会触发同步 layout，导致强制回流；应改用 CSS 自定义属性 + calc()、限制嵌套层级、避免 auto-fit 冗余轨道，并优先使用 grid-template-areas 声明式布局。
grid-template-columns 频繁变更直接触发同步 layout
每次 JS 修改 grid-template-columns 字符串（比如从 "1fr 2fr" 改成 "2fr 1fr"），浏览器必须立刻执行完整的轨道尺寸计算（track sizing）——包括测量所有子项内容、处理 minmax() 边界、分配 fr 剩余空间、再重算 gap 影响。这不是异步任务，而是强制同步回流（Layout Thrashing）。
常见误操作：
- 在
scroll或mousemove回调里直接改style.gridTemplateColumns - 用
ResizeObserver监听容器变化后，未节流就立即更新列定义 - 把
grid-template-columns当作“状态变量”在 React/Vue 的响应式更新中高频重设
用 CSS 自定义属性 + calc() 替代字符串拼接
把可变部分抽成 --col-ratio 这类 CSS 变量，让布局逻辑留在 CSS 引擎内，避免 JS 干预 layout 触发点。
例如：
立即学习“前端免费学习笔记（深入）”；
.grid {
--col1: 1;
--col2: 2;
grid-template-columns: calc(var(--col1) * 1fr) calc(var(--col2) * 1fr);
}JS 只需改变量值：el.style.setProperty('--col1', '2')。浏览器不会重新解析整条 grid-template-columns 规则，只做轻量级的 calc 重计算。
注意：
- 不要写
calc(var(--col1) fr)（缺乘号会解析失败） - 变量值必须是纯数字，不能带单位或表达式
- 搭配
requestAnimationFrame批量更新多个变量，确保单帧内完成
auto-fit 列数自动调整时，空轨道仍是性能负担
repeat(auto-fit, minmax(250px, 1fr)) 看似智能，但浏览器仍要为“理论上可能存在的每一列”预留轨道槽位。当容器宽 1200px、最小列宽 250px 时，它会预建最多 4–5 条轨道，即使只渲染 2 个子项。
更糟的是：若子项高度不均，grid-auto-rows 又设了 minmax(100vh, auto)，每新增一个子项都可能触发整行重排。
优化方向：
- 确定性列数场景（如表单字段对齐），改用
repeat(3, minmax(250px, 1fr))+grid-auto-flow: dense - 不确定数量但需严格控制轨道数，加
max-width限制容器宽度，避免生成冗余轨道 - 配合
display: contents移除无内容的包裹节点，减少参与轨道计算的元素数
嵌套 Grid 中父层 fr 单位会放大子层计算开销
当外层是 grid-template-columns: 1fr 2fr，内层又用 repeat(auto-fit, minmax(300px, 1fr))，浏览器必须反复回溯：先算外层每列实际像素宽 → 再按该宽度算内层能塞几列 → 再检查内层子项内容是否撑爆 → 最后修正外层轨道。三层以上嵌套时，这个链式推导会让 layout 时间呈指数增长。
移动端尤其敏感，iOS Safari 15.4 前、旧版 Android WebView 对 intrinsic sizing 的优化极弱。
可行解：
- 首屏区域 Grid 层级严格 ≤ 2 层
- 必须嵌套时，子网格用固定列宽（如
120px 120px）或minmax(0, 1fr)跳过最小内容测量 - 结构稳定区域优先用
grid-template-areas，把布局逻辑压到声明阶段，而非运行时推导
真正卡顿的从来不是 Grid 语法本身，而是你让浏览器在 layout 阶段反复做「测量→分配→验证→修正」的循环。减少轨道变动，本质是减少浏览器被迫同步读取样式和布局信息的次数。
