瀑布流布局终于有了正确的打开方式

还记得第一次做瀑布流布局时的绝望吗？Pinterest 那种错落有致的照片墙，看起来简单，实现起来却让人头大。要么引入 Masonry.js 这种几十 KB 的库，要么自己写一堆 JavaScript 计算每张图片该放哪儿。更要命的是，屏幕一变大小，所有计算都得重来一遍。

我一直在想，都 6202 年了，这事儿为啥还这么复杂？

直到最近看到 WebKit 团队发布的 CSS Grid Lanes，我才发现——原来瀑布流布局，真的可以只用 3 行 CSS 搞定。

3 行 CSS，搞定你想要的瀑布流

先看代码：

.container {   display: grid-lanes;   grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));   gap: 16px; }  

就这样。没有 JavaScript，没有媒体查询，没有复杂的计算。浏览器会自动把内容塞进合适的列里，就像下面这样：

瀑布流照片墙效果

在三行 CSS 中，无需媒体查询或容器查询，我们创建了一个适用于所有屏幕尺寸的灵活布局。

把布局想象成高速公路堵车

Grid Lanes 的工作原理其实很好理解。想象你在高峰期开车上高速：

高速公路堵车示意图

每辆车（网页上的每个元素）都想往前挤，哪条车道最空就往哪儿并。Grid Lanes 也是这个逻辑——浏览器会把下一个元素放到“最靠近顶部”的位置，就像司机换车道抢位置一样。

不只是照片墙，它能做的更多

看到这儿你可能会想：“瀑布流不就是放照片嘛，我平时用不着。”

别急，Grid Lanes 的应用场景比你想的多得多。比如这个报纸式的文章布局：

报纸式文章布局

头条横跨 4 列，重点文章占 2 列，其他文章单列排列——这种在杂志上常见的不对称设计，以前要写一堆定位代码，现在只需要：

article:nth-child(1) {    grid-column: span 4;  } article:nth-child(2), article:nth-child(3) {    grid-column: span 2;  }  

再比如网站底部那种塞满链接的 Footer:

Mega Menu 布局示例

每组链接的高度都不一样，但它们能自动紧密排列，不留大片空白。这在以前几乎是不可能用纯 CSS 实现的。

横着来还是竖着来？随变来

Grid Lanes 还有个贴心的设计：你可以自由选择“瀑布式”（竖着排）还是“砖墙式”（横着排）。

两种布局方式对比

想要瀑布式？定义列：

.container {   display: grid-lanes;   grid-template-columns: 1fr 1fr 1fr 1fr; }  

想要砖墙式？定义行：

.container {   display: grid-lanes;   grid-template-rows: 1fr 1fr 1fr; }  

浏览器会根据你定义的是列还是行，自动判断该往哪个方向排布内容。这个新加的 normal 默认值会帮你处理好一切。

“ item-tolerance”让布局更聪明

Grid Lanes 还引入了一个新概念：item-tolerance。

还是用堵车来比喻。假设左边车道的车比右边车道的车短 5 厘米，你会为了这 5 厘米就换车道吗？大概率不会，因为这点差距根本不值得折腾。

Grid Lanes 也一样。默认 item-tolerance: 1em 意味着：只有当两个位置的差距大于 1em 时，浏览器才会“换车道”排列元素。小于这个值？就当它们一样高，按顺序排就行。

容忍度效果对比

兼容性现状

说了这么多激动人心的特性，该泼点冷水了——Grid Lanes 目前的浏览器支持情况，怎么说呢，有点尴尬。

现状是这样的：

目前，只有 Safari Technology Preview 234 实现了 display: grid-lanes 这个语法。注意，这还只是预览版浏览器，连 Safari 正式版都还没支持。换句话说，你现在想在生产环境用？不好意思，还得再等等。

不过，其他浏览器其实早就有各自的瀑布流实现了：

• Chrome/Edge: 在 Chromium 140 里搞过 display: masonry，现在正忙着改成 grid-lanes
• Firefox: 人家 2020 年就实现了，用的是 display: grid 语法，也得跟着标准改
• Safari 17: 之前也是用 display: grid 来实现的

这就像大家本来各说各的方言，现在终于决定说普通话了，但都还在学习阶段。

对比一下传统的 CSS Grid:

传统的 CSS Grid Layout 从 2017 年 3 月起就被所有主流浏览器支持了。Chrome 57+、Firefox 52+、Safari 10.1+、Edge 16+ 全都没问题，全球浏览器兼容性评分高达 97 分。

而 Grid Lanes？现在连正式版浏览器都还没一个支持的。

预计时间线：

保守估计：

• 2026 年上半年: Safari 正式版可能会支持
• 2026-2027 年: Chrome/Edge/Firefox 陆续跟进实现
• 真正生产可用: 至少还要等 1-2 年

在那之前，我们还得继续用 Masonry.js 或者 CSS 多列布局（column-count）作为过渡方案。

但也有好消息：

这次各大浏览器厂商终于在标准上达成一致了！不再像以前那样各搞各的私有前缀、各自为政。大家都朝着 grid-lanes 这个统一标准努力，这本身就是个巨大的进步。

标准的统一比特性的抢先更重要。这次浏览器厂商们难得达成共识，虽然实现还需要时间，但方向是对的。

说实话，当我看到这个特性时，第一反应是：“哇，终于有人把这事儿做对了。”

我们常说“用对的工具做对的事”，但很多时候，是因为没有对的工具，我们才不得不用错的方式硬搞。瀑布流布局就是典型——它本质上是个布局问题，却一直要靠 JavaScript 解决。这就像用螺丝刀钉钉子，能用，但总觉得哪里不对劲。

Grid Lanes 的出现，让布局回归布局，让 CSS 做它该做的事。更重要的是，它展示了一个好的 Web 标准应该是什么样：简单、直观、性能好，还能向后兼容。

Mozilla 打下基础，WebKit 团队花了三年多时间实现，CSS 工作组反复讨论打磨——这才有了今天我们看到的 Grid Lanes。

期待它正式发布的那天。到时候，我们终于可以把那些瀑布流库从项目里删掉，换上 3 行干净的 CSS 了。