Grid 网格布局这些年反复被提起，可真把它用明白的人，并不算多。我带前端新人时最常看到这样一个画面：垂直居中会用 Flexbox，做导航条会用 Flexbox，一旦要搭“左边菜单、右边内容、顶上栏、底下栏”这种整页骨架，就开始一层一层疯狂嵌套，最后自己都分不清结构跑哪去了。这时候我就会把话题拉回到 Grid 网格布局——它不是 Flexbox 的升级版，而是另一套思考方式：你不再操心“一条队伍怎么排”，而是直接面对一张棋盘，行列同时落子。很多同学入门 Grid 是从阮一峰老师的教程开始的，那套文章把语法讲得很细，但真正落到项目里，语法之外还有一堆决策和坑没人替你总结。这篇文章就是我带项目、做重构时攒下来的实战复盘，适合两类人：刚学完 Flexbox 想往 Grid 进阶的，以及明明会用 Grid 却总在响应式、隐式网格上翻车的。
1. 为什么说 Grid 是“二维王者”，Flexbox 撑死算“一维排队”
1.1 一维与二维的本质差异
Flexbox 的核心是主轴。你写justify-content、align-items，本质上都在跟一条主轴和交叉轴打交道。一排按钮、一条导航、一行表单控件，这些“单方向排列”的需求，Flexbox 确实顺手。但有个问题：一旦内容多到需要“换行”，Flexbox 的换行是自动流式的，它不会帮你管理“换行后前后元素对齐”这种二维关系。
我给你举个例子。一个商品卡片墙，3 列、每列 4 个卡片，右上角还有个需要精确对齐的标签。用 Flexbox 做，你首先得保证容器宽度刚好放下 3 列，然后每列的flex: 1还得处理换行后卡片高度不齐、最后一行孤零零挂在左边的问题。最后你通常要包一层又一层的 wrap 容器，用负 margin 去抵消间距，这是典型的“用一维工具硬扛二维需求”。
Grid 网格布局不一样。一旦display: grid，你面对的是一个坐标系：grid-template-columns定义横向轨道，grid-template-rows定义纵向轨道，子项直接落在两者的交叉点上。行和列之间天然存在结构关系，不需要你再靠容器嵌套去维持。这才是“二维”这个词的真正含义。
1.2 像下围棋一样，先圈地盘再落子
我用“下围棋”来类比 Grid，是因为它俩的关键动作完全一致：先想清楚地盘怎么划，再决定棋子往哪放。
一个页面布局通常长这样：顶部导航、左侧侧边栏、中间内容区、底部版权条。用 Flexbox 的惯性思维，你脑子里是一个接一个的横条，每个横条里再做内部排列。用 Grid 的思维，你第一件事是在纸上画格子：这个页面大致分成几行？几列？哪块区域占多少行、多少列？棋盘的边界先定下来，后面所有内容都只是往网格里落子。
我自己的习惯是：写任何 Grid 布局之前，先开一个空白文档，用文字写出来：
- 第 1 行：高度 64px，占满整行
- 第 2 行：高度 1fr，左列 260px、右列占剩余
- 第 3 行：高度 48px，占满整行
写完这个，才动手敲grid-template-areas。这个习惯帮我省了特别多调试时间，因为后面所有子项的位置都不需要再纠结——区域已经圈好了，元素放进对应的“格子”就行。做布局的核心决策发生在“划分棋盘”阶段，而不是“摆放棋子”阶段，这是 Grid 和 Flexbox 最大的心智差异。
2. 搭棋盘的核心属性：网格模板与区域命名
2.1 用 grid-template-columns 和 rows 定义骨架
一个最简单的 Grid 骨架只需要三行代码：
.app { display: grid; grid-template-columns: 260px 1fr; grid-template-rows: 64px 1fr 48px; height: 100vh; }这里grid-template-columns声明了两条纵向轨道：固定 260px 的栏位，以及一份 1fr 的弹性栏位。grid-template-rows声明了三行：顶部 64px、中间尽可能伸展、底部 48px。子项默认会按顺序自动放进网格，但只靠这种“自动流”方式，子项多了以后谁也记不住第几个元素落在哪个格子，而且一旦增删元素，整个布局就乱套。
所以我更推荐直接指定子项位置。最常见的是网格线编号方式：
.sidebar { grid-row: 1 / 3; grid-column: 1 / 2; } .main { grid-row: 2 / 3; grid-column: 2 / 3; }这里的数字是网格线的编号，不是列号。起始线从 1 开始，第一行和第二行之间的线是 2，依此类推。负值也可以：最末一根线是-1，倒数第二根是-2。少数新手会踩一个坑：以为grid-column: 1 / 2是“占据第 1 列”，实际上它表示“从第 1 根线到第 2 根线”，也就是跨过 1 条轨道，确实占据第 1 列。但如果写grid-column: 1 / span 2，意思就变成“从第 1 根线开始，跨越 2 条轨道”，两者的差别必须记清楚。
2.2 区域命名：把布局写成一张地图
网格线编号虽然精确，但可读性一般。项目一复杂，看着满屏1 / 3、2 / 4，维护的人头大。我的实际做法是优先用grid-template-areas，直接把布局“画”出来：
.app { display: grid; grid-template-columns: 260px 1fr; grid-template-rows: 64px 1fr 48px; grid-template-areas: "header header" "sidebar main" "footer footer"; height: 100vh; } .sidebar { grid-area: sidebar; } .header { grid-area: header; } .main { grid-area: main; } .footer { grid-area: footer; }你看到grid-template-areas的字符串，就能一目了然整个页面的结构：第一行左右都是 header，第二行左边是 sidebar、右边是 main，第三行整行是 footer。每个区域名对应一个矩形区域，同一名称出现多次，就表示这一块区域要跨越多行或多列。
这里有几个细节必须提醒：
- 区域名不能是关键字，尤其不能用
span。我用grid-area: span这种命名踩过一次，整个区域解析直接报错，那个排查过程让人记忆深刻。 - 空单元格用
.表示，一个点占一个格子，多个点连写也可以，比如". . side"。 grid-area简写的顺序是：grid-row-start / grid-column-start / grid-row-end / grid-column-end。所以grid-area: 1 / 1 / span 2 / span 3表示从第 1 行、第 1 列开始，跨 2 行、跨 3 列。
区域命名的最大好处是：后期调整布局时，只改grid-template-areas这几行字符串，子项完全不用动。一个后台项目的侧边栏想从左边挪到右边，你只需要改字符串的排列，CSS 复杂度不增加，这个体验用过就回不去了。
3. 让列宽“有脾气”：fr、minmax、auto 的搭配心法
3.1 fr 的分配逻辑：先满足固定，再分剩余
1fr大概是 Grid 里最常见的单位，但很多人对它有个误解：以为它等同于flex: 1。表面上效果有点像，本质却不同。fr是网格轨道专用单位，它的分配策略是：优先满足固定尺寸轨道之后，再把剩余可用空间按比例分给各个 fr 轨道。
举个具体的例子。假设容器宽度 1200px，代码：
grid-template-columns: 200px 1fr 2fr;200px 的固定轨道先拿走 200px，剩下 1000px 由两个 fr 轨道按 1:2 切分。结果就是中间列约 333px，最右列约 667px。如果去掉那个 200px 固定轨道，变成1fr 2fr，剩余空间就是全宽 1200px，中间列 400px，最右列 800px。这种“先固定、后弹性”的顺序特别适合侧边栏加内容区的组合：侧边栏宽度不让，内容区在剩余空间里自由伸缩。
还有一点容易忽略：fr 轨道之间不会因为内容多寡而互相挤压大小，它们只按比例分配空间。这一点跟flex-grow很像，但 flex 子项还会受到flex-shrink和flex-basis的影响，整体行为更绕。Grid 的 fr 是在表现上更干净的一种弹性方案。
3.2 minmax()：给轨道装上底线
只用1fr有个隐患：容器变窄时，fr 轨道虽然会跟着缩，但如果里面内容很长，内容可能把轨道撑破，或者轨道缩到比预期还小。这时候就要上minmax()。
minmax(最小长度, 最大长度)给轨道设一个下限和上限。最常见写法是：
grid-template-columns: 260px minmax(0, 1fr);这里最有价值的不是1fr，而是minmax(0, 1fr)。如果你直接写1fr，轨道等价于minmax(auto, 1fr)，也就是最小尺寸由内容决定。假如内容区里有一个很长的代码块，或者一张超宽图片，轨道会被内容撑到比视觉预期宽得多，造成溢出。而minmax(0, 1fr)把下限压到 0，轨道可以由网格算法自由缩小，溢出问题的根子就解决了。
配合响应式设计，我常用的一个套路是：
grid-template-columns: repeat(auto-fill, minmax(220px, 1fr));每个轨道至少 220px，有多余空间就按 220px 的整数倍“播种”更多轨道，剩下的空间再让所有轨道均分。这样卡片在宽屏下自动增多，在窄屏下自动减少，不用写媒体查询也能适配。关于 auto-fill 的具体表现，下一节展开。
3.3 一个容易翻车的点：min-width 和溢出
Grid 子项默认的min-width: auto，这是很多人忽略的坑。子项里如果有长英文文本、超长链接、大图，它会优先保住内容的最小宽度，把整个网格轨道撑开，最终表现为“布局破掉了”。
我踩过的一个案例是给商品卡片套了 Grid，卡片里有价格区间和促销标签，促销标签用了white-space: nowrap，结果整个卡片在窄屏下死活不肯压缩，右侧直接溢出页面。排查半天，问题就出在子项没有min-width: 0。
给网格子项补上：
.card { min-width: 0; overflow: hidden; }是一个成本极低但能解决大量诡异溢出的操作。你在任何 Grid 布局里遇到“为什么这条轨道比计算值宽”“为什么页面多出横向滚动条”，第一反应都应该是去检查子项的min-width和轨道是否用了minmax(0, 1fr)。
4. 响应式与对齐：auto-fill 的孪生陷阱和 place-* 简写
4.1 auto-fill 与 auto-fit：一对长得太像的双胞胎
我用repeat(auto-fill, minmax(220px, 1fr))做卡片墙时，第一次就踩了 visual 上的大坑。容器里只有 3 张卡片，容器宽度 1000px，理论上能放下 4 个 220px 的轨道。auto-fill 会真的创建 4 条轨道，哪怕只有 3 个元素，第 4 条轨道仍然空在那里，所以页面上就出现了一片空白。
把代码改成 auto-fit 情况就完全不同：
grid-template-columns: repeat(auto-fit, minmax(220px, 1fr));auto-fit 会先把轨道全部创建出来，如果元素不够填满所有轨道，那些“空轨道”会被折叠为 0 宽度，然后已有的轨道拉伸，把容器填满。同样是 3 个元素、容器 1000px，用 auto-fit 结果是 3 个卡片平均占满整行，每个约 320px，视觉上很饱满。
一句话记忆法：auto-fill 偏爱“空位也要占着”，auto-fit 偏爱“填满不留缝”。做卡片墙、数据看板，我默认用 auto-fit；做那种需要保持固定列位、元素数量可能动态增删的“网格骨架”，才用 auto-fill。
4.2 justify-items、align-items 和 place-* 的对齐逻辑
Grid 里有两组对齐属性，分别看内容对齐和容器对齐。子项在网格区域内部的对齐用justify-items（水平）和align-items（垂直），它们的默认值是stretch，也就是子项会拉伸填满整个网格区域。很多新手第一次用 Grid 发现按钮“变宽变高”了，就是因为默认的 stretch 在起作用。
我常用的对齐简写是place-items：
.center { display: grid; place-items: center; }这一行顶替了align-items: center; justify-items: center;，配合height: 100vh就是最干净的“整页居中”方案。还有一组place-content，控制的是整个网格轨道在容器里的分布，类似 Flexbox 的justify-content，只在容器空间大于轨道总尺寸时有意义。这两组别搞混了，items管子项，content管整体。
4.3 一个真实案例：不写媒体查询的自适应卡片墙
给你一个可以直接抄的卡片墙用法：
.cards { display: grid; grid-template-columns: repeat(auto-fit, minmax(240px, 1fr)); gap: 20px; padding: 20px; } .card { min-width: 0; padding: 16px; border: 1px solid #e5e7eb; border-radius: 8px; }容器从 320px 的手机屏一直拉到 1440px 的桌面显示器，卡片列数会自动从 1 变成 2、4、5，全程不用一条媒体查询。间距统一用gap处理，不要去给卡片加 margin。因为 gap 是作用于轨道之间的，计算轨道宽度时 grid 是整体在算，不容易出现 Flexbox 那种“margin 造成最后一行挤压”的问题。这大概是我在项目里用 Grid 用得最爽的场景——少删了上百行媒体查询代码。
5. 隐式网格和子项越界：新手最容易崩溃的地方
5.1 显式网格与隐式网格的差别
你用grid-template-columns和grid-template-rows定义出来的轨道，叫显式网格。但 Grid 不要求子项数量必须刚好等于格子数量。一旦子项超出了定义范围，多出来的元素自动落在“隐式创建”的轨道上。
举个最常见的场景：
.grid { display: grid; grid-template-columns: repeat(3, 1fr); }容器里放了 10 个div。前三行共 9 个格子都能放，第 10 个元素去哪了？Grid 会默默在下方新增一行隐式行。问题在于，隐式行的高度默认是auto，也就是由内容决定。如果第 10 个元素内部有很高的小组件，这一行会突然变得巨大，和上面 9 个格子的高度完全不一致。
解决办法是显式控制隐式轨道：
.grid { display: grid; grid-template-columns: repeat(3, 1fr); grid-auto-rows: minmax(100px, auto); }grid-auto-rows只作用于隐式创建的行，给这些行一个最小高度 100px，内容更高就自动扩展。同理，竖着排方向时用grid-auto-columns。如果你在数据列表场景下频繁遇到“行高乱七八糟”，大概率就是 grid-auto-rows 没设。
5.2 grid-auto-flow: dense：填洞还是保持顺序，得想清楚
子项尺寸不规则时，网格里会出现空洞。比如第一个元素grid-column: span 2占了两列宽，它后面的元素就可能被挤到下一行，留下一个洞。grid-auto-flow: dense可以让后来的元素主动往前填洞，视觉上更紧凑，看板、瀑布流卡片经常这么用。
但代价是元素的视觉顺序不再等于 DOM 顺序。重度依赖 Tab 键访问或者用屏幕阅读器的用户，读屏顺序会和你看到的视觉顺序不一致，这是可访问性上的硬伤。我的原则是：注重阅读顺序的内容流（文章、表单）坚决不用 dense；面向管理后台的看板类组件，在团队明确知道取舍的前提下才用。
5.3 一个表格型 Grid 的完整排查过程
做过一个项目，前端要把一份接口返回的数据渲染成类似表格的布局：
.grid-table { display: grid; grid-template-columns: 80px 2fr 1fr 1fr; }短信列表、状态标签、操作按钮都放进这个网格。上线后测试反映：状态标签那一列在某种文本长度下会突然变宽，把整体列宽顶乱，最后一列被挤出容器。
我的排查链路是这样走的。先打开浏览器控制台，给网格容器画上 overlay，看轨道计算值。发现第 3 列的实际宽度比预期宽，追到标签上有一个white-space: nowrap和一个很长的枚举文案。再查子项，默认min-width: auto让标签内容拥有了“不可压缩”的最小宽度，轨道被它撑到 220px 以上。
修复方案分两步：容器轨道写成minmax(0, 1fr)，确保轨道可以收缩；标签自身设置text-overflow: ellipsis; overflow: hidden;，让长文案截断而不是强撑。改完以后，任意长度的文案都不会再把布局撑破。这件事给我的经验是：Grid 再强大，也架不住内容破坏性 padding 和 min-width 的夹击，出问题先从这两个点找。
6. Grid 和 Flexbox 不是二选一，而是配合战
6.1 判断标准其实很朴素
很多人纠结一个页面到底该用 Grid 还是 Flexbox，我给团队定的标准非常简单：一次排列里同时要考虑行和列，用 Grid；只考虑一条主轴的排列，用 Flexbox。
“做整页骨架”几乎必然是二维的，选 Grid。“做一排面包屑”“做一组操作按钮”，用 Flexbox 的flex: 1、gap就够了，硬套 Grid 反而增加模板代码。这不是谁取代谁的问题，而是工具半径的问题：Flexbox 的特长是“一条线上怎么分”，Grid 的特长是“整个面怎么划”。
6.2 骨架归 Grid，零件归 Flexbox
一个后台页面的外壳，我通常这么搭：
.app { display: grid; grid-template-columns: 220px 1fr; grid-template-rows: 64px 1fr; grid-template-areas: "sidebar header" "sidebar main"; height: 100vh; } .sidebar { grid-area: sidebar; } .header { grid-area: header; } .main { grid-area: main; }顶栏内部的菜单、用户信息、通知图标，再用 Flexbox 去排：
.header-nav { display: flex; align-items: center; gap: 16px; } .header-nav .right { margin-left: auto; }Grid 把空间的“大结构”锁死，Flexbox 处理“结构内部的排列细节”。这里最大的好处是，以后无论子项怎么增删，只要不跨区域，页面的整体框架就永远不会抖动。Flexbox 负责的那些菜单选项，增删时也只影响那一行内部的排列，不会连累别的区域。
6.3 这种组合为什么更省代码
我做过一次技术债清理，把老项目中一层套一层的 flex 布局改成 Grid 加 Flexbox 的组合，改动后的样式文件直接少了将近三分之一。原因在于：用 Flexbox 模拟二维布局，需要容器嵌套、比例计算、负 margin 修正，这些都属于“为了布局而造的辅助代码”。而 Grid 用轨道和区域把结构直接表达出来，不需要那么多中间容器。
维护性提升更是明显。后来同事改需求，把内容区从两栏改成三栏，只动一行grid-template-columns，加上改一下子项的 grid-area 或者让它自动流动即可，整个改动不到十行。这在以前用 Flexbox 嵌套实现的时候是不可想象的。从团队协作角度讲，写好 Grid 的代码本身就是一种文档：打开grid-template-areas就能读懂页面结构，比任何注释都直观。
这几年 AI 辅助编码的能力越来越强，有人开玩笑说前端迟早要远离 Grid、让 AI 来生成布局。我的体感恰恰相反：AI 能帮你写出一百行语法正确的代码，但帮不了你判断为什么页面右侧空了一块、为什么卡片被长文本撑破、为什么 dense 打乱了阅读顺序。这些问题的根子都在“你心里有没有那张棋盘”。Grid 网格布局真正教给我的，不是多记几个属性，而是先看全局、再落子、最后兜底的处理方式。如果你也想彻底掌握它，我建议找一天，把自己项目里的登录页或者个人中心，断开文档硬写一遍 Grid 骨架，把 auto-fit、minmax、grid-auto-rows 轮着用一遍。踩完这些坑，你对二维布局的理解就真正立住了。
