八年了：我们用 JavaScript 硬撑的“瀑布流”，终于被 CSS 亲手埋了
dev约 7 分钟你一定经历过。
你在做一个 Pinterest 风格的照片墙，或者一个博客首页——那种卡片错落、参差有致、看起来“高级到不讲道理”的布局。你顺手一搜“masonry layout CSS”，然后就掉进兔子洞：一堆 JavaScript 库、一堆“看似能用”的偏方、一堆在手机上直接碎成渣的方案。
我上个月为了一个“很简单”的图片网格，硬生生折腾了三个小时。 三个。小时。
图片就是对不齐。间距就是不对。浏览器窗口一缩放……别提了，简直像看着自己辛苦搭的积木当场塌方。
那种痛？ 它刚刚变成历史。
我们所有人都在“偷偷黑”的那种布局
瀑布流（masonry layout）这东西，怎么说呢——它几乎是 CSS 八年来的白鲸。
你知道我说的是哪种画面：Pinterest 那种不同高度的图片，像被一只看不见的手“塞进”各列里——没有尴尬的大空洞，列与列之间像水一样自然流动，怎么滑都顺。
我们当然有过替代方案。 哦，别说“替代”，简直是“求生”。
我用 David DeSandro 的 Masonry.js 用到快背下 API 了。与此同时，我也被 CSS columns 折磨过：内容会从上到下流，而不是从左到右排；视觉好看，阅读顺序却常常离谱。更别提那个更“玄学”的 CSS Grid 伪解法：你在网格里写 grid-row: span 50，而这个 50 还得靠 JavaScript 先算像素高度再换算出来——一边算一边祈祷别出错。
这些方案都“能用”。差不多能用。直到它们突然不能用。
八年：开发者一直在说“能不能拜托你们……”
你听过一个很离谱的事实吗？
第一个“正式请求 CSS 支持 masonry”的提案，早在 2017 年就开了。 也就是说，整整八年，开发者一直在问同一句话：“我们能不能就……简单点？给个原生的办法？”
问题不是没人想做。问题是：CSS Working Group 在语法上吵不拢。
它到底应该是什么？ 是一个新的 display 类型？还是 Grid 的扩展？又或者干脆新增一组全新的属性？
他们甚至争论过一堆名字：display: collapsed-grid、display: stacked-grid、display: masonry-grid……以及更多你看了只想扶额的候选。
开发者参与讨论，浏览器厂商做实验实现，会议一场接一场，争论一轮接一轮。Jen Simmons（WebKit 团队）在某次会议里还说过一句很直白的话：她“个人非常失望”，因为五年来几乎没什么进展。
那是 2024 年。 而那时，这个争论已经持续了七年。
所以你看，问题从来不是“有没有人需要”。 问题是：大家一直卡在“到底怎么做才算对”。
然后，突然就通了
2025 年 12 月 19 日。WebKit 丢出一个公告，直接让我这个写前端的人心跳漏一拍：CSS Grid Lanes 来了。
不是“快了”。不是“草案”。不是“未来某天”。 是“来了”。而且就在 Safari Technology Preview 里。
语法？简单到有点不真实：
.container {
display: grid-lanes;
grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
gap: 16px;
}
就这？ 就这三行。
没有 JavaScript。没有算高度。没有“求你别在平板上崩”。
这到底改变了什么
让我把它翻成“人话”，你会立刻懂它的含金量。
以前：你要做一个照片墙。你先花时间装 Masonry.js，再配配置；然后你得确保图片加载后才初始化；接着你要调试为什么移动端不对；你还可能要补懒加载脚本；最后你只能祈祷某次依赖更新不会把你线上布局炸掉。
现在：你写那三行 CSS。完事。 浏览器自己处理剩下的一切。
图片会自动流进各列，尽可能“贴紧”摆放。你缩放窗口？它会自动重排。你加图片？它会自动填坑。键盘用户 Tab 过去？焦点顺序也更合理——不是那种跳来跳去、像被幽灵拖着走的体验。
更妙的是：它继承了 CSS Grid 的完整表达能力。也就是说，你仍然能用你熟悉的 grid-template-* 做各种花活，比如：
做交替宽度的列：
grid-template-columns: repeat(auto-fill, minmax(8rem, 1fr) minmax(16rem, 2fr)) minmax(8rem, 1fr);
让某些项目横跨多列：
article:nth-child(1) {
grid-column: span 4;
}
把元素固定在某些“lane”里：
header {
grid-column: -3 / -1; /* 永远在最后两列 */
}
你熟悉的 Grid，那套能力还在；然而这次，它终于能配合“瀑布流的自然流动”一起工作了。
那个“高速公路”比喻，终于让我彻底明白它在干嘛
WebKit 团队用一个特别形象的类比：把每个 item 当成高速公路上的车。
每一辆车都想尽量往“路的前方”开——也就是尽量靠近顶部。 新车进来时，会选择那个能让它离前方最近的车道（lane）。所以元素就会自然落在“当前最短的那一列”，效果就像 Pinterest 那样紧密填充。
但真正聪明的地方在于：他们加了一个叫 tolerance（容差） 的机制。
想象一下：一列高度 501px，另一列 500px。你真的希望第七个元素为了省那 1px，就突然跳去右边吗？那会导致布局看起来很“抖”，而且可访问性更糟：键盘 tab 的顺序会变得混乱、像随机抽奖。
所以默认情况下，item-tolerance 是 1em。只有当差距大过这个阈值，布局才会“认真考虑”换 lane。换句话说：它优先保证逻辑与可读性，而不是偏执地追求像素级最优。
你甚至可以更“佛系”一点：
.container {
display: grid-lanes;
grid-template-columns: repeat(4, 1fr);
item-tolerance: 2em; /* 放松点，别为小差距乱跳 */
}
它不止一种玩法：竖着流，也能横着流
有个点我一开始没想到：Grid Lanes 不只会做“瀑布流”（往下排的 waterfall）。
如果你定义的是 rows，而不是 columns，它会做一种“砖墙式”布局：内容从左到右流，像砖一样横向堆叠：
.container {
display: grid-lanes;
grid-template-rows: 1fr 1fr 1fr; /* 现在变成水平流动 */
}
浏览器会根据你用的是 grid-template-columns 还是 grid-template-rows，自动推断流动方向。 你不用再写一堆“如果……否则……”。它就——工作了。
我真的试了：然后它就真的……行了
我下载了 Safari Technology Preview。 我拷了一个 WebKit 的 demo。 我随手改了几个数字。
然后它就……工作了。
没有构建步骤。没有库。没有那种“为什么 Safari 这样、Chrome 那样”的精神消耗型调试。
我五分钟做了一个“博物馆画廊”式布局：每幅画大小不同，流进八列，标题固定占最后两列。接着我又试了一个 mega menu 的 footer：几十组链接、每组高度不同。放在以前，这类东西我至少要花半天去“驯服 JavaScript”，现在却是“写完就成”。
比如这种：
.container {
display: grid-lanes;
grid-template-columns: repeat(auto-fill, minmax(max-content, 24ch));
column-gap: 4lh;
}
没有洞。没有怪间距。就是贴合、就是顺、就是漂亮。
当然有坑（因为世界从不白送）
目前它只在 Safari Technology Preview 234 里。 不在正式版 Safari。也不在 Chrome、Firefox、Edge。
但你别急着泄气，因为另一个事实也很关键：各大浏览器其实早就做过 masonry 的实验实现，只是都在 flag 后面、各玩各的：
Chrome 以前有过 display: masonry的尝试Safari 走过一条 Grid-based 的路线 Firefox 早在 2020 年就有过探索
现在 Safari 用 grid-lanes 在 Technology Preview 里先跑起来，其他浏览器也在跟同一份规范的方向推进。也就是说，最难的“概念统一”基本结束了，接下来更多是“怎么把语法对齐并正式上线”。
CSS Working Group 现在还在敲定一些细节，比如：
flow-direction 属性到底叫什么最合适 item-tolerance会不会改名为pack-tolerance一些 shorthand（简写）应该怎么设计
尽管如此，核心模型已经定了；命名还在动，但大概率只是小修小补。因此你现在就可以开始学习它的基本模式——未来即便改语法，也不会把你的理解推倒重来。
现在你该怎么做
你现在还不能把它直接上生产。 不过你真的应该开始玩它。
下载 Safari Technology Preview。去拆它。去折腾它。去做 demo。去看看它在你自己的组件库里能玩出什么怪物。
因为当它跨浏览器落地的那一刻——而且它一定会落地——你会希望自己已经“熟到闭眼写”。到那时，你的竞争对手还在加载 50KB 的 JavaScript 做瀑布流，你只需要三行 CSS 就能把页面做完，还更稳、更易维护、也更友好。
想看实际效果？WebKit 有一堆 demo（原文地址写的是 webkit.org/demos/grid3/）：
会自动重排的照片墙 可以让主文章跨列的报纸排版 带定位标题的博物馆展品墙 终于说得通的 mega menu footer
你甚至可以做点“更野”的：发到 Bluesky 或 Mastodon，@Jen Simmons，告诉大家：当布局原语真的到位时，Web 能长成什么样。
真正的故事，其实不只是“瀑布流”
这件事更像一场“八年拉锯战”的结局。
它是开发者八年如一日地说“我们需要这个”，然后浏览器厂商真的在听。它是 CSS Working Group 在无数次争论之后，终于找到共识。它是 Web 平台终于愿意用“原生能力”，承接我们过去十年一直用 hack 硬凑出来的模式。
你正在见证一个 CSS 功能从“要是有就好了”，走到“它就是这么工作的”。这种时刻不多见，也因此更值得兴奋。
为了把几个盒子叠起来就加载一坨 JavaScript 的日子？ 它们正在倒计时。
你的下一套照片墙，会是三行 CSS。 你的下一份报纸式布局，会自己长好。 你的下一版作品集，会在所有设备上自然流动，而且不需要一行脚本。
这未来从今天开始——只要你愿意去试。
现在就去：下载 Safari Technology Preview 234，复制这段起步代码，做点东西，拆点东西，搞坏点东西。然后你会明白：八年的争论，最终给了我们什么。
我们曾经一直在“黑”的那个布局—— 马上就要变成原生了。 而且，它会非常美。