很多人学 CSS Grid 时，最容易被"网格"这两个字带偏，以为只要写上display: grid，再配几列几行，子元素就会乖乖听话地待在格子里。真正上手做项目以后才会发现，最磨人的往往不是grid-template-columns写不出来，而是"多出来的元素到底该往哪儿放""为什么这里空了一块没人填"这类自动排列问题。而这些问题，归根到底都绕不开grid-auto-flow这个核心属性。这篇文章我想把自己在实际布局中围绕grid-auto-flow踩过的坑、总结出的规律完整讲一遍，尽量说人话，看不懂算我输。

1. 先从"显式网格"和"隐式网格"说起：grid-auto-flow 管的是哪一段

1.1 你写好的轨道，只是网格的"正规军"

先明确一个概念：当你用grid-template-columns和grid-template-rows定义列轨和行轨时，这些轨道被称为"显式网格"。它们是网格的骨架，是你在代码里明确承诺过要存在的行和列。

但实际项目里，内容的数量往往不是你写死行列时就能精确控制的。拿一个后台系统的卡片看板来说，你预估了一行放四张卡，一共放两行，也就是八张卡。结果产品经理突然说"再塞两张推荐卡进来"。这时候网格容器里的子元素从八个变成了十个，显式网格只有 2x4 八个格子。多出来的两个元素去哪？浏览器不能把它们丢出容器外，于是会自动创建新的轨道来容纳它们。这些浏览器自动创建、没有经过grid-template-*声明的轨道，就是"隐式网格"。

1.2 隐式网格里的排序规则，就是 grid-auto-flow 的核心职责

隐式网格轨道创建出来之后，还有一个更现实的问题：它的排列方向是往右还是往下？这可不是浏览器随便决定的事，grid-auto-flow就是用来指定这条"数据流"方向的属性。官方默认值是row，意思是横向优先、逐行填充，排满一行后再排下一行；column则反过来，逐列填充，排满一列后再排下一列；再加上dense关键字，还可以让后面的元素回填空隙，实现"紧凑模式"。

我见过不少刚接触 Grid 的人，会在隐式轨道上栽跟头，因为他们在容器上写了grid-template-columns: repeat(4, 1fr)，却忘了grid-template-rows，也没设置grid-auto-rows。结果所有子元素排成四列后，第二行开始的行高完全由内容撑开：有的卡片是图片，撑得老高；有的卡片只有一行文字，矮扁得贴在顶部。视觉上参差不齐，怎么调都难受。这不是grid-auto-flow的锅，而是因为你没有管理隐式轨道的尺寸。但它俩经常是一起出场的：grid-auto-flow决定隐式轨道往哪个方向追加，grid-auto-rows/grid-auto-columns决定追加出来的轨道多宽多高。理解了这一层，才算真正解锁自动网格的完全体。

为了后续讨论方便，我先给出一个基准容器：

.board { display: grid; grid-template-columns: repeat(3, 1fr); grid-template-rows: repeat(2, 100px); gap: 8px; grid-auto-flow: row; /* 默认值，写不写都一样 */ }

代码块里grid-auto-flow: row是我显式写出来的，虽然它是默认值，但对阅读代码的人来说，这算是一种"意图声明"。

2. row 与 column：自动排列的方向，决定了容器的扩展方式

2.1 默认的 row 模式：先横向填满，再纵向扩展

在默认grid-auto-flow: row下，浏览器的自动放置算法大致这样走：从左上角第一个格子开始，逐格往右放置元素；当前行放不下就换下一行；显式网格行放完了但元素还没放完，就向下追加隐式行。

继续用上面的容器例子：board里一共六个格子，但如果你放了八个子元素，第七个和第八个就会被放进新创建的第三行。第三行不属于grid-template-rows: repeat(2, 100px)的定义范围，所以它的默认高度是auto，也就是由内容决定。很多时候你以为是"行高怎么没生效"，其实就是因为这行是隐式行，走的是grid-auto-rows而不是grid-template-rows的逻辑。

row 模式最适合的场景很常规：文章列表、商品卡片、照片墙这类"上面一行放几个，下面再接着放"的阅读顺序。它和人类久经考验的书写方向、阅读节奏都是一致的，因此也是最不容易出意外、最适合拿来做容器基座的模式。

2.2 column 模式：变成纵向优先的数据流

grid-auto-flow: column是另一种极端的视觉习惯。它从左上角第一个格子开始，逐格往下放；当前列放完就换右边一列；显式网格的列不够用，就向右追加隐式列。

我最早用 column 模式，是在一个横向时间线页面上：左侧是年份，右侧是当年发生的事件，中间一根竖线串联。实现上很适合用grid-auto-flow: column，给每列一个固定宽度，行数固定为几行，然后让事件按列从上往下排。如果事件很多，浏览器会非常自然地在右侧追加新的一列，完全不用手动断行。

简单例子：

.flow-column { display: grid; grid-template-rows: repeat(3, 80px); grid-auto-columns: 220px; grid-auto-flow: column; gap: 12px; overflow-x: auto; }

这段代码的关键点是：我只声明了三行，没声明列宽，但用grid-auto-columns: 220px声明了后续出现的隐式列宽度。子元素会有序地排成三行一列、三行两列……超出部分就成了横向滚动。如果你把grid-auto-flow: column和grid-auto-columns分开看，效果就没那么直观了，但理解了"方向 + 轨道尺寸"这套组合拳之后，写起来会顺手很多。

2.3 方向选择的三个判断点

面对一个具体布局，我一般用三个问题来判断到底选 row 还是 column：

• 内容的主增长方向是横向还是纵向？如果用户添加一条数据，你希望它出现在右侧，那 column 更贴合；如果希望出现在下方，用 row。
• 有没有固定容器高度，允许宽度无限扩张？比如表格区的横向滚动，column 几乎就是为这种情况设计的；反过来，固定宽度向下滚动的瀑布流，row 是更直白的选择。
• 哪个维度需要受控？如果你希望行数可控、列数跟随内容增加，使用grid-auto-flow: column+grid-template-rows声明固定行数；如果你希望列数可控、行数跟随内容增加，使用默认 row +grid-template-columns声明固定列数。

这个选择过程，比死记"row 是横向、column 是纵向"有用得多，因为它直接把属性和容器扩展方向绑定了。

3. dense 关键字：看起来是"填空"，实际上会打乱顺序

3.1 默认的稀疏模式会留下什么坑

默认的自动排列是"稀疏"的。什么意思？就是每个元素严格按照从左到右、从上到下的顺序找自己的下一个格子，前面有坑也不管，宁可空着也不让后面的元素倒回去填。

举个例子。容器是四列网格，元素 A 占了两个格子宽，元素 B 占四个格子宽，元素 C 占两个格子宽。A 放在第一行第一二列，B 放在第二行第一到四列，C 只能放到第三行第一二列。结果第一行第三四列会空着，但 C 不会回填到那个空隙里——因为在稀疏模式下，算法扫描到的空隙不会阻止后面的元素继续往后找位置，它真的就是"往前找、绝不回头"。

这在照片墙、卡片列表里非常难看：明明右边有一个空格，后面的小卡片却宁可换到下一行去，留出个刺眼的空白。于是我们手动了grid-auto-flow: row dense。

3.2 dense 的填充规则：回填，但有前提

dense不是简单地把所有元素都往左上角塞。它的规则是：在保持网格项自身跨行跨列的前提下，只要前方出现了能放得下的格子，就优先塞进去，即使这个格子"诞生"在文档顺序更早的元素之前。

上面那个例子里，加上 dense 以后，C 会被塞回到第一行第三四列的空格中。视觉效果立刻变得紧实，不再有空洞。对于大量不等高、不等宽的内容，比如 Masonry 风格的瀑布流，dense 几乎是救命的。

但前提务必说清楚：dense 只能影响"自动放置"的元素。如果一个元素通过grid-column: 1 / 3之类的显式定位被固定到了特定位置，那就不会被 dense 算法回填或挪动。

3.3 使用 dense 前必须接受的代价

许多人尝到 dense 的甜头后，顺手在整个容器上开启dense，然后会发现一件诡异的事：屏幕阅读器和键盘 Tab 焦点的顺序，跟视觉上看到的顺序不一样了。

因为 dense 本质上是"视觉优先、文档顺序靠后"的算法。元素 A 在 DOM 里排在前面，视觉上可能被安排到第二行；元素 D 在 DOM 里排在后面，视觉上却出现在第一行。用户在屏幕上看到的阅读顺序和读屏软件朗读出的顺序、键盘逐项切换的顺序，完全是两套。这对普通用户可能无感，但对依赖辅助技术的用户来说，会产生实实在在的困惑。

我的处理原则是：dense只用在纯展示型内容上，比如图片画廊、瓷砖墙、非交互的卡片陈列；只要网格项里存在链接、按钮、表单控件，或者需要依赖源顺序表达因果关系的列表，我宁可接受空白，也不轻易开启 dense。布局美观可以让开发走查磨合，可访问性一旦出问题，不是几行 CSS 能救回来的。

4. 只配 direction，不配 auto 轨道尺寸，等于埋雷

4.1 grid-auto-rows 和 grid-auto-columns 的定位

我把grid-auto-flow比作地铁的方向指示牌："新轨道往这边开"。但指示牌不负责告诉你"新轨道要多宽"。隐式轨道自身的宽度与高度，由grid-auto-columns和grid-auto-rows来负责。

如果没有显式设置这两个属性，隐式轨道的尺寸是auto。auto在实际渲染中约等于"内容多宽我就多宽"，或者"内容多高我就多高"。很多新手被这个行为坑过：明明没有grid-template-rows，只写了grid-template-columns和grid-auto-flow: row，实际出来的行高忽高忽低，完全不受控。加一行grid-auto-rows: minmax(80px, auto)问题就解决了。

4.2 一个横向滚动面板的完整配置

结合上面的话题，我经常把column和grid-auto-columns一起用。举一个真实的团队管理面板例子：每个成员占一列，每列底部是操作按钮，列固定宽度 260px，行数为 4 行。成员不断增加，列自动向右延伸，容器滚动。

.team-scroller { display: grid; grid-template-rows: repeat(4, auto); grid-auto-columns: 260px; grid-auto-flow: column; gap: 16px; overflow-x: auto; padding-bottom: 8px; }

grid-template-rows: repeat(4, auto)我故意设置成 4 行，这是为了在竖向上形成稳定分组。成员的卡片结构可能高度不等，所以 row 用auto，但横向的列必须统一，所以grid-auto-columns: 260px确保新列不是随内容宽度漂移的。

注意这里的顺序：grid-auto-flow只解决了方向，真正让横向滚动整齐的，是grid-auto-columns。我敢说不少人的横向滚动布局到了项目后期出现列宽不一致、内容挤压变形，问题就出在没设置好这个"配角"。

4.3 auto 轨道的 minmax 习惯

再补一个细节：我几乎不给隐式轨道单独写死一个固定尺寸。上午设计的行高 100px，下午后端塞进来一段长文本，直接就溢出了。所以我习惯写成grid-auto-rows: minmax(100px, auto)。minmax的意思是：轨道最小值 100px，但内容需要时可以继续撑大。既不浪费视觉空间，又不挤出内容。

这个写法听着简单，但能解决一个高频 bug："为什么我设置了行高，卡片里的文字还是挤到外面"。原因往往是行高写死，内容放不下，默认情况下 Grid 会溢出，而不是自动撑开。给自动轨道留一条auto后路，才是稳妥的方案。

5. 组合实战：自动排列、跨行跨列和调试的真实体验

5.1 让 dense 和 span 协作，做出紧凑卡片墙

下面这段是我实际项目里用到过的一个紧凑卡片布局片段，组合了grid-auto-flow: row dense和span。

.wall { display: grid; grid-template-columns: repeat(4, minmax(0, 1fr)); grid-auto-rows: minmax(120px, auto); grid-auto-flow: row dense; gap: 12px; } .wall .feature { grid-column: span 2; grid-row: span 2; } .wall .wide { grid-column: span 3; } .wall .tall { grid-row: span 2; }

.feature占四格（2 列 x 2 行），.wide占三列，.tall占两行。单独出现span时，每个元素都在声明自己的大小；配合dense，浏览器会在不改变元素自身尺寸的前提下，努力不让前方出现空洞。最终的效果很像拼贴画：所有格子严丝合缝，卡片有大有小但整体没有留白。

值得注意的是，没有dense时同样的 span 配置很容易出现"右侧一条缝"。这也是我为什么强调 dense 的价值：它做的是把碎片化的空隙重新利用起来，而不是缩小任何网格项。

5.2 显式定位元素不会参与自动排列

边界情况也很重要。网格项一旦用了grid-column: 2、grid-row: 3、grid-area: header这类确定性定位，它就脱离了 auto-placement 算法管辖，grid-auto-flow对它完全无效。这些元素依然存在于网格里，会占据实际位置，但自动放置算法在选择格子时会主动绕开它们。

一个常见的意外是：你以为开了dense就能把所有空格填满，结果某些位置还是空着。检查一下是不是有元素被grid-area显式放到了一个犄角旮旯，或者某个元素设置了grid-column-end指到了很远的地方。这个坑不看 DevTools 的网格面板很难发现，因为代码里确实写了 dense，逻辑却绕不过显式定位。

5.3 用浏览器开发者工具排查自动排列问题

排查grid-auto-flow相关问题时，我比写代码更依赖 DevTools。在 Chrome 中选中网格容器，Elements 面板里就能看到工具栏上的 Grid 覆盖图层。开启"显示行号/列号"后，可以直观看到每个网格项的摆放位置，以及有没有隐式轨道被创建出来。

再配合"显示网格区域名称"和"显示轨道尺寸"，能迅速判断出一处空白到底是显式轨道里的空洞，还是隐式轨道创建方向不对。建议你动手改grid-auto-flow时，保持 DevTools 网格覆盖一直是打开状态，肉眼比对结果，比反复刷新页面高效得多。另外，如果发现容器莫名其妙出现了你从未写过的第三行，就把覆盖图层打开看轨道颜色，新创建的隐式行在棋盘图里通常颜色更深，那大概率就是grid-auto-rows没写或者写错了方向。

6. 最后想叮嘱的三件事

• 先想清楚由谁控制数量。每写一套 Grid，先问自己：列数要固定还是行数要固定？明确以后，grid-auto-flow的方向基本就定死了：想控制列数用 row，想控制行数用 column。不要靠感觉盲试。
• dense 是有代价的高级技巧。它能填空洞，却会重排视觉顺序。只给纯展示内容用，别让按钮、表单、长文出现在 dense 容器里。项目里如果真要用，一定要让交互测试去走一遍 Tab 键，确认没有把关键操作顺序打乱。
• 隐式轨道尺寸永远要配套。写grid-auto-flow时顺手检查下有没有写grid-auto-rows或grid-auto-columns。这两组属性就像方向盘和车轮，只给方向不给尺寸，最终跑出来的车一定摇摇晃晃。

我在实际项目里对grid-auto-flow的态度，是把它当成 Grid 布局的"最后一块拼图"：先定显式轨道，再定自动方向，最后定隐式轨道尺寸。按这个顺序理下来，几乎不会出现"子元素跑偏""莫名蹦出一行""卡片中间空一截"之类的玄学问题。如果你手头正好有一个怎么调都填不满的网格布局，不如先从grid-auto-flow检查起，八成能一眼看出问题所在。