Grid布局本身不慢，但滥用隐式网格、过度嵌套或高频js修改会显著拖慢渲染；高效写法包括用grid-template简写、auto-fit+minmax响应式列、统一gap代替margin。
Grid布局本身不慢，但写法决定快不快
Grid 是浏览器原生支持的二维布局引擎，解析和渲染效率远高于用 javaScript 模拟的网格（比如早期 Masonry 库），也比浮动 + 清除、绝对定位等“黑魔法”更轻量。但它不是“写了就快”——性能瓶颈往往出在滥用隐式网格、过度嵌套或频繁重排上。
- 隐式网格行（implicit grid rows）容易被忽略：没定义
grid-template-rows时，内容撑开的行会动态生成，浏览器需反复计算高度，拖慢首次渲染 - 深层嵌套 Grid 容器（比如 Grid 里再套 Grid，再套 Grid）会让浏览器 Layout 树变深，重排成本指数级上升
- 用
grid-column-start等属性在 JS 中高频修改（如拖拽排序、滚动高亮），会强制触发布局重计算，卡顿明显
怎么写 Grid 才真正高效？关键三条实操规则
不是少写几行 css 就叫优化，而是让浏览器“一眼看懂你要什么”，减少猜测和回溯。
- 用
grid-template简写代替分开写grid-template-rows/grid-template-columns/grid-template-areas：解析更快，代码更紧凑 - 响应式列数优先用
repeat(auto-fit, minmax(250px, 1fr))，而不是媒体查询里重复写三套grid-template-columns：减少 CSS 规则数量，也避免断点跳跃时的 layout shift - 间距统一用
gap，别用margin：gap不参与外边距折叠计算，也不影响项目盒模型，浏览器跳过一堆判断逻辑
.grid-container { display: grid; grid-template: 'header header' 60px 'nav main' 1fr 'footer footer' auto / 200px 1fr; gap: 12px; }哪些 Grid 写法会悄悄拖垮页面？
这些看似无害的操作，在中大型页面或交互密集场景下，极易引发可观测的卡顿或 CLS（累积布局偏移）：
- 在动画或滚动中动态改
grid-template-areas：每次修改都会触发整块网格重生成，chrome DevTools 的 “Layout Shift Regions” 面板能立刻标红 - 给大量项目（>50 个）逐个设置
grid-row和grid-column：CSS 解析器要为每个项目做独立定位计算，不如用命名区域批量控制 - 用
fr单位但没设最大约束，比如grid-template-columns: 1fr 1fr 1fr在超宽屏下无限拉伸，导致文本行过长、重排压力增大
对比 flexbox，Grid 什么时候该上、什么时候该收？
不是越“高级”的布局方式就越适合所有场景。Grid 强在结构规划，弱在单项目微调；Flexbox 反之。
立即学习“前端免费学习笔记（深入）”；
- 用 Grid 做整体骨架：页头、侧边栏、主内容区、页脚的二维划分——
display: grid+grid-template-areas最清晰 - 用 Flexbox 处理内部排列：导航菜单项水平居中、卡片内按钮右对齐、表单项标签与输入框对齐——
display: flex更轻量、更可控 - 别用 Grid 实现单行/单列的“伪 Flexbox 效果”：比如只有一行的按钮组还写
grid-template-columns: repeat(3, 1fr)，纯属增加解析负担
Grid 的快，是建立在“结构明确、边界清晰、变更克制”的前提上的。最容易被忽略的，其实是把 Grid 当成万能胶——哪都粘一下，结果粘得越多，浏览器算得越累。