纯CSS实现瀑布流：从Columns到Grid的完整指南

瀑布流布局大家应该都不陌生，就是那种 Pinterest 风格、高度参差不齐的多列网格。前几年想做这种效果，基本绕不开 Masonry 这类 JS 库，或者自己用 JS 算位置、写绝对定位，一套流程下来繁琐不说，性能也容易出问题，尤其是图片一多、页面一长，滚动的时候能明显感觉到卡顿。

这几年 CSS 本身的能力一直在增强，Flex 布局解决了大部分一维排列的问题，Grid 布局把二维网格彻底拿下了，但瀑布流这种“纵向排列、高度不等、又要像水流一样自然填充”的需求，一直没有一个特别干净利落的 CSS 原生方案。好消息是，现在情况变了，用纯 CSS 实现瀑布流不仅可行，而且有不止一种思路。这篇文章我就把自己实际项目中验证过的方案、踩过的坑、以及一些容易被忽略的细节全部整理出来，希望对你有实际帮助。

1. 从 JS 到 CSS：瀑布流方案的演进与选型思路

先说个背景。瀑布流这个需求本身不难理解，就是让内容块像砖墙一样错落有致地排列，每块的高度不固定，但整体视觉上左右两侧要尽量齐平，不能出现一边特别高一边特别矮的情况。早年间的实现方式，我印象很深，当时第一个项目就是用 jQuery 插件做的，核心逻辑就是监听图片加载、计算每一列的高度、然后把新的元素塞到当前最矮的那一列里。这套逻辑本身没毛病，但它带来的问题不少：第一，必须等图片加载完才能算出准确高度，否则布局会跳；第二，所有的计算都在 JS 里做，元素一多，浏览器的主线程压力很大，滚动时会掉帧；第三，窗口尺寸变化时要重新计算，代码写得稍微不严谨就会出现重叠或者缝隙。

后来 CSS Grid 出现了，很多人试着用 grid 来做瀑布流，但标准的 grid 有个天生的限制，它要求每个单元格都在一个隐形的网格里，行和列都是对齐的，做不到那种错落参差的感觉。除非你把一个元素的网格跨度设成两行，但这样下一行就会出现空缺，也就是所谓的“网格空洞”，视觉上还是不自然。所以纯 CSS 的瀑布流方案，真正落到实处的主要是两个方向：一个是 column 多列布局，另一个是升级版 Grid 玩法，配合 grid-row 跨行实现无空洞排列。再往前看一步，CSS 官方其实已经在推进原生的 masonry 布局模块，但截至我写这篇文章时，浏览器的支持度还不太理想，生产环境暂时不建议依赖它。

我的项目里最终选的是什么组合方案呢？核心是用 CSS Grid 配合 grid-row: span 来实现一个既可以横向阅读、又能自然填充的高性能瀑布流。而 column 方案我会用在一些内容比较轻、不需要严格横向顺序的场景里。下面的章节我会把这两种方案拆开来讲，包括具体的代码写法、参数怎么算、以及各自的适用边界。

2. CSS Columns 方案：最轻量的瀑布流实现

2.1 核心代码与实现原理

CSS 多列布局其实是相当老的一个属性了，它最初的设计目的是为了模拟报纸那种多栏排版效果。但歪打正着，它也能用来做瀑布流。实现代码简单到了令人发指的地步：

css复制.masonry-columns {
  column-count: 4;
  column-gap: 24px;
}

.masonry-columns .item {
  break-inside: avoid;
  margin-bottom: 24px;
}

这段代码就完成了瀑布流的全部核心布局。column-count 控制列数，column-gap 控制列间距，子元素的 break-inside: avoid 是关键中的关键，它告诉浏览器，这个元素内部不允许被分割，也就是说每个 item 必须完整地待在某一列里，不能被截断到两列。

原理上也很好理解，浏览器会把容器里的内容自动按列高度均匀分配，先填满第一列，再填第二列，以此类推。这种方案最大的优点就是简单，不需要任何 JS，也不需要担心图片加载后的高度波动，因为浏览器会自动调整内容分配。

但要注意一个细节，很多文章里还在用 page-break-inside: avoid 或者 -webkit-column-break-inside: avoid 这类老写法，其实现在只需要写标准的 break-inside 就够了，兼容性已经非常稳定。不过在某些比较老的 Webview 内核里，如果发现卡片被截断，可以加一个 display: inline-block 或者 display: table 来兜底，这是一个很有效的兼容技巧。

2.2 这个方案的明显短板

如果你只是做一个简单的照片墙，或者一个轻量的资讯流，column 方案完全够用。但如果你要做一个商品瀑布流、一个图片分享社区，或者任何需要“从左到右、从上到下”阅读顺序的场景，这个方案就会露馅了。

问题出在内容的填充顺序上。column 布局在排列元素时，是先把第一列填满，再填第二列。也就是说，用户看到的第一个商品在第一列最上面，第二个商品在第一列第二个位置，以此类推。在中文阅读环境下还好，但在很多产品里，我们希望用户横向对比商品，也就是第一行能看到四个商品、第二行看到另外四个。这种情况下 column 布局的阅读顺序是断裂的，用户从上往下刷，其实一直在看第一列的内容，等到第一列到底了才会跳到第二列。这个体验在电商场景里是致命的，用户会觉得信息混乱，对比困难。

还有一个问题是列数不可控。column-count 指定了列数之后，在窄屏设备上如果不加媒体查询，内容会被硬塞进四列里，每个卡片变得特别窄。虽然也可以用 column-width 来让浏览器自动计算列数，但配合响应式设计时要额外写很多断点，不够省心。

所以这个方案我把它的定位定在：内容形式统一、不需要严格横向顺序、追求代码极简的场景。比如团队介绍页、案例展示墙、或者文章标签云这类内容。

3. CSS Grid 方案：真正能打的瀑布流新解法

3.1 关键思路：让卡片自己决定跨几行

接下来是重头戏，用 CSS Grid 实现无空洞瀑布流。这个方案的核心思路是利用 grid-auto-rows 加上 grid-row: span 来自动跨行。基本写法是这样的：

css复制.masonry-grid {
  display: grid;
  grid-template-columns: repeat(4, 1fr);
  grid-auto-rows: 8px;
  gap: 16px;
}

.masonry-grid .item {
  grid-row: span 24;
}

这里需要解释一下。我们把网格的基础行高设为 8px，然后每个卡片通过 grid-row: span 24 告诉浏览器：我要占据 24 行，也就是 24 × 8 = 192px 的高度，再加上 gap 的间隔，实际占据的垂直空间就是 192px 加上一个间距。如果内容更高，就把数值调大，比如图片高度是 300px，那么 span 的值可以设为 38，因为 38 × 8 = 304px，足够覆盖图片高度。

但这里有一个更容易被忽略的核心技巧：grid-row: span 的值必须由内容自身的高度决定。如果所有的卡片设置相同的 span 值，那就退化成了一个普通网格，没有任何瀑布流效果。真正的瀑布流，需要每张卡片根据自己的内容高度设置不同的 span 值。这就引出了两种做法，一种是 JS 计算高度后给每个元素设置内联样式，另一种是预设几个档位，利用 CSS 类名来控制。实际项目中我更推荐后者，比如这样：

css复制.masonry-grid .item.h-tall {
  grid-row: span 40;
}

.masonry-grid .item.h-medium {
  grid-row: span 28;
}

.masonry-grid .item.h-short {
  grid-row: span 18;
}

提前定义好三档高度，前端渲染的时候根据内容的类型、图片的比例来打类名。这样既保留了 CSS 布局的优势，又不需要精确到像素级的计算，性能非常好。

3.2 Grid 方案的原理深度拆解

为什么这个方案能实现瀑布流而不产生空洞？关键在 grid-auto-rows 和 grid-row: span 的配合逻辑里。

我们先把容器定义成一个网格，每列宽度为 1fr，每一个行轨道的高度是 8px。浏览器渲染时，会先按顺序放置每个 item，放置时把这个 item 的起始行设为当前自动放置光标所在的位置，然后根据 span 的值占据相应的行数。这里的关键在于，Grid 的自动放置算法会尝试把每个元素放进当前行中第一个能容纳它的网格区域。

举个例子，第一行四个格子，假设第一个卡片 span 30，那么它占据了第一列前 30 行。第二个卡片 span 20，它被放在第二列前 20 行。第三个卡片 span 30，放在第三列前 30 行。第四个卡片 span 18，放在第四列前 18 行。到这里没有空洞，但接下来第五个卡片就很有意思了，浏览器会从第一列开始搜索，发现第一列的第 31 行已经空了，会尝试把第五个卡片放进去，如果第五个卡片 span 25，那么它正好从第 31 行放到第 56 行，比第二列的第 21 行要低，所以第二列的空隙会被后续的元素填充。简单来说，Grid 的自动放置算法天然会寻找 “第一个有足够空间的地方”，这个行为和人工实现瀑布流的逻辑几乎一致——都是找最短列、塞进去、更新列高。只是 Grid 把这个过程交给了浏览器原生布局引擎，效率远高于 JS 模拟。

还有一个隐藏的优点在于，这个方案对图片加载后的高度变化不敏感。因为容器的行高是固定的 8px，即便一张图片的加载导致整个 item 的内容变高，只要 span 的值不变，网格结构就不会乱，唯一可能出现的是 item 内部的内容溢出到 item 的边框之外。针对这种问题，只需要在 item 上设置 overflow: hidden，或者确保 item 内部图片按照固定的高度显示（比如 aspect-ratio），就完全可控了。

可能有人会问，为什么行高要选 8px 而不是 1px 或者 20px？我这里解释一下，8px 是一个经验值。如果选得太小，比如 1px，那么每一行的容量太小，需要占据的 span 值特别大，写起来不方便；如果选得太大，比如 20px，那么 span 的粒度太粗，卡片之间的高度会有明显的阶梯感，看起来不够自然。8px 是一个接近像素级、但又不是 1px 那样夸张的折中值，配合上 gap 使用，卡片之间的视觉间距可以被精确控制。

4. 实操过程中遇到的性能与兼容性细节

4.1 响应式布局的断点设计

Grid 方案在响应式上的处理比 column 方案要优雅一些。因为列数是用 grid-template-columns: repeat(4, 1fr) 写死的，所以只要在不同断点下覆盖列数，以及对应的 span 值即可。比如：

css复制@media (max-width: 1024px) {
  .masonry-grid {
    grid-template-columns: repeat(3, 1fr);
  }
}

@media (max-width: 640px) {
  .masonry-grid {
    grid-template-columns: repeat(2, 1fr);
  }
}

但这里有个细节容易踩坑：当列数从 4 变成 3 时，grid-row: span 24 这个值是需要同步调整的。因为列数越少，卡片在水平方向占据的宽度越大，要保持图片的比例，高度自然也要变大。如果不动 span 的值，在窄屏下卡片会被压缩得很扁，或者在宽屏下被拉得太高。最简单的做法是配合媒体查询，同时调整 .item 的类名映射，或者干脆使用自定义属性来控制：

css复制.masonry-grid {
  --item-span: 28;
}

.masonry-grid .item {
  grid-row: span var(--item-span);
}

@media (max-width: 1024px) {
  .masonry-grid {
    --item-span: 34;
  }
}

这种做法的好处是，不同的高度档位可以分别定义变量，比如 --item-span-tall、--item-span-medium、--item-span-short，然后在媒体查询里统一调整基准值，代码会干净很多。

4.2 图片加载与布局抖动问题

使用 Grid 方案做瀑布流，和 column 方案相比，布局抖动的问题要更突出一些。因为 column 方案的内容分配完全由浏览器计算，图片加载不会影响排列顺序；而 Grid 方案的每个 item 占据的行数是写死的，如果 item 内部的图片还没有加载出来，item 的实际高度可能会小于我们设置的 span 高度，导致下方出现空白区域，等图片加载完成后，图片又会把 item 撑大并溢出。

我的解决方案分两步。第一步很关键，给图片容器设置一个固定的宽高比，比如用 aspect-ratio: 1 或者 aspect-ratio: 4 / 3，这样即便图片还没有加载，容器已经占有了正确的高度，item 的实际高度从渲染一开始就是正确的。第二步是配合 content-visibility: auto 属性，这个属性可以让浏览器跳过屏幕外元素的渲染工作，对滚动性能有质的提升，但它会因为裁剪内容而导致高度计算不准确，所以不要直接用在 item 本身，而是用在 item 内部的内容块上，或者用 contain-intrinsic-size 来指定一个预估高度，让浏览器在未渲染时也知道该留多少空间。这两个属性配合起来，长列表的滚动性能基本可以达到原生滚动的体验。

4.3 兼容性测试与降级策略

CSS Grid 本身的兼容性其实已经非常好了，所有现代浏览器都支持，甚至 IE 11 都有部分支持。但 grid-row: span 配合 grid-auto-rows 的这套玩法，在 IE 11 上是不行的，IE 的旧版 Grid 语法需要额外加 -ms- 前缀，而且自动放置算法的行为和新版差别很大。不过我个人的建议是，除非你们的业务还在强依赖 IE，否则没必要为这个老掉牙的浏览器付出额外成本。如果确实需要做降级，最简单的办法是加一个特性检测：

css复制@supports (grid-auto-rows: 8px) {
  .masonry-grid {
    display: grid;
    grid-template-columns: repeat(4, 1fr);
    grid-auto-rows: 8px;
  }
}

@supports not (grid-auto-rows: 8px) {
  .masonry-grid {
    display: flex;
    flex-wrap: wrap;
  }
}

在降级方案里，用 flex 布局让卡片左对齐排列，虽然没有了参差错落的瀑布流效果，但至少能保证内容完整可读。对于不支持 @supports 的老浏览器，默认的块级流式布局也能兜底，只是视觉效果朴素一些。

5. 常见问题与排查技巧实录

5.1 Grid 元素内部溢出与文本截断

在使用 Grid 方案时，最常见的问题就是 item 内部的文本或者图片超出了卡片区域。大部分原因在于 span 的值设得太小，实际内容高度超过了设定的行数。排查的办法也很简单，打开开发者工具，选中 item 元素，查看它的网格区域高亮范围，如果内容底部超出了高亮范围，那就是 span 不够。另一种隐蔽的情况是 item 内部使用了绝对定位的元素，而父元素没有设置 position: relative，导致内容定位到了外层容器上，这种问题在排查时要先确认样式的包含关系。

5.2 使用 Column 方案时卡片被截断

break-inside: avoid 已经写上了，但某些卡片仍然会从中间断开，跑到下一列去了。这个常见原因有两个：一是卡片的父元素设置了 display: flex 或 display: grid，导致内部的 break 相关属性没有按预期生效，这种情况可以尝试把卡片内部的结构改成普通块级元素；二是图片等媒体元素本身有高度变化，在 break-inside 的计算中产生了歧义。还有一个别被忽略的：break-inside 是标准的 CSS 属性，但是如果你在写的时候加上了 -webkit- 前缀，部分新版浏览器反而会忽略前缀版本、只认标准版本，导致旧写法和新写法混用后行为不一致。最好是只保留标准写法，如果需要兼容老浏览器，加前缀时两者的值必须一致。

5.3 为什么我的 Grid 瀑布流会出现空位

这个问题我调试了很久才弄明白。当我在 item 上设置了 margin-bottom 来增加卡片间距时，Grid 的自动放置算法在计算行高时不会把 margin 算进去，导致某些卡片实际占据的高度超过了其网格区域，下一个卡片就被挤到更远的行去了，视觉上就出现了空位。正确的做法是不用 margin 来调整间距，而是用 gap 或 row-gap，或者把 margin 改成 item 内部元素的 padding。这里我整理了一张速查表，方便对照排查：

6. 我踩过的一些坑与最终选型建议

最后再聊一点掏心窝的话。我最早在做这个瀑布流项目时，一开始用的是 column 方案，因为代码确实太吸引人了，五行样式搞定一切，但后来产品经理拿了一张标注了阅读顺序的交互图过来，说用户必须横向看到不同价位段的商品，我才意识到 column 在这个场景里是致命的。换了 Grid 方案之后，虽然代码量多了一些，但整个布局的行为变得完全可控，不管是横向顺序还是纵向补位，都在预料之中。

在实际落地时，如果你的技术栈是 Vue 或者 React，不要把 span 值写死在静态 CSS 里。最好的做法是让组件根据传入数据的类型动态绑定一个类名，比如图片比例是 1:1 就用 h-tall，视频卡片就用 h-extra-tall，纯文本卡片用 h-short。这样布局的灵活度会高很多，也方便后续遇到新的内容类型时直接增加一个档位，而不用去改布局算法。

还有一个小技巧是，当你需要支持无限滚动加载时，不要用传统的 appendChild 方式往 Grid 容器里塞节点，因为那会触发整棵布局树的重新计算。可以给容器定义一个固定的高度或者使用 grid-auto-flow: dense，让后续插入的元素利用之前的空隙自动填充。dense 这个属性值很有意思，默认情况下 Grid 自动放置算法会跳过空洞不填，但设置 dense 之后，它会优先填补前面留下的空隙。缺点是有可能出现视觉上顺序跳跃，比如第一列空了三个格子，新加载的元素会被塞到那里，而不是排在最后。如果产品上没有严格的顺序要求，dense 是提升空间利用率的利器。我最终的方案里没有加 dense，因为顺序在我的业务场景里比空间利用率更重要，这个取舍需要根据你自己的场景来判断。

CSS 原生的 masonry 模块我已经在 Chrome 的实验性功能里试过了，它对 grid-template-rows: masonry 这种写法确实能做到非常自然的效果，代码也很简洁。但目前的兼容性让人望而却步，生产环境里贸然使用风险很大。等哪天它的支持度覆盖了主流浏览器，我一定会把它作为首选。在那之前，基于 CSS Grid 的这套 grid-row: span 方案，就是当前最靠谱、最能打的原生瀑布流解法。