配了八年瀑布流，今天发现根本不用写那800行JS了——grid-template-rows: masonry把这件事彻底变了

做过 Pinterest 风格图墙的都懂这个痛：设计师甩过来一个瀑布流稿子，你盯着看半天，心里已经开始盘算「又要调 JS 算定位了」。

过去十年，瀑布流基本三个方案：column-count 顺序是乱的、 Masonry.js 加载时抖、自己写 JS 算高度，复杂项目能写到八百行。维护过这套东西的同事，你应该也听他们骂过。

今天这件事彻底变了。

一行 CSS，浏览器自己会算

CSS Grid 规范第三版加了一个 grid-template-rows: masonry 的属性，2026 年 Chrome、Safari、Firefox 全部稳定支持。写起来是这样：

.gallery {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));
  grid-template-rows: masonry;
  gap: 12px;
}

没了。子元素什么都不用写，浏览器自己按最短列往上填，紧密排列，不留空隙。

为什么 Flexbox 做不了这个

有人问 Flexbox 不是也能做瀑布流吗？能做，但做出来是错的。

flex-direction: column + flex-wrap: wrap 确实能出多列布局，但子元素是按列从上往下排到底才换列，用户看到的顺序是：

1 4 7
2 5 8
3 6 9

瀑布流真正要的是：

1 2 3
4 5 6
7 8 9

用 Flexbox 硬做出来的，要先 JS 按列拆分数组再渲染，那个恶心程度谁写谁知道。CSS Grid masonry 直接在布局引擎里原生处理了这件事。

配合 aspect-ratio 解决图片跳闪

瀑布流最常崩的地方是图片异步加载：DOM 渲染时图片高度是 0，masonry 按 0 高度排，等图加载完突然撑开，跳闪甚至错列。

不用写 JS 监听 load 事件，也不用给固定高度（会拉伸图）。直接用 aspect-ratio 告诉浏览器「这个容器宽高比是固定的」，浏览器就能提前留好正确空间：

.gallery img {
  aspect-ratio: 4 / 3;
  object-fit: cover;
}

兼容性与降级

目前 Chrome 116+、Safari 16.4+、Firefox 100+ 都支持。在不支持的浏览器里，它会静默退化为普通网格自动排列，不会报错也不会错位。如果你的瀑布流有强烈的时间顺序依赖（比如信息流），需要注意这个退化行为。

下一步

如果你的项目还在用 Masonry.js 或者自己写的瀑布流 JS，现在可以跑一遍这个流程：

1. 替换为 display: grid + grid-template-rows: masonry
2. 去掉 JS 高度计算逻辑
3. 加上 aspect-ratio 占位
4. 测一遍 Safari 和 Firefox

三行 CSS 替换八百行 JS，这件事今天彻底变了。