配了八年瀑布流，每次都要靠 Masonry.js 算位置——今天 grid-template-rows: masonry 把这件事彻底原生化了

做过瀑布流卡片的开发者都知道这件事有多烦：图片高度不一，传统 Grid 没办法让下一行接着上一行的空位填上去，所以要么用 Masonry.js 这样的 JS 库硬算，要么用 CSS columns 把布局方向改成垂直列排。两条路各有各的代价——JS 要占用主线程做重排，容易触发 Core Web Vitals 的 CLS 和 INP 问题；CSS columns 虽然零依赖，但阅读顺序是从上到下排完第一列再排第二列，和 DOM 顺序不一致，SEO 和无障碍都是坑。

Safari 26.4 上周悄悄把 grid-template-rows: masonry 做进了稳定版，Chrome 121+ 和 Firefox 77+ 也陆续跟进，Interop 2026 把这条路正式列进了跨浏览器兼容性重点方向。这意味着瀑布流第一次可以用纯 CSS 原生方式做了，不需要任何 JS 依赖。

三行代码，告别 30KB 库

核心用法就这么简单：

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

grid-template-rows: masonry 告诉浏览器：这一行的高度不需要你手动算，交给布局引擎自己填。浏览器会在渲染时自动把每个卡片塞进当前最短的那一列，跟 Masonry.js 的贪心算法逻辑完全一样——但这是 GPU 加速的合成器线程操作，不卡主线程。

如果你需要横向瀑布流（类似 Pinterest 的竖列布局），把 masonry 换到另一个轴：

.grid {
  grid-template-rows: repeat(3, auto);
  grid-template-columns: masonry;
}

三个细节决定能不能上线

masonry-slack 控制打包松紧度。默认是 0，卡片之间严丝合缝；设成 1rem 会给每列之间留点呼吸空间，适合视觉上想故意留白的设计：

.gallery {
  grid-template-rows: masonry;
  masonry-slack: 1rem;
}

多列跨度完全支持。做产品展示墙的时候想让某张卡片占两列宽度，直接 grid-column: span 2 就好，浏览器会自动把这个卡片的宽度算进最短列的分配逻辑里：

.featured-card {
  grid-column: span 2;
}

无障碍和 DOM 顺序完全一致。CSS columns 的老大难问题——屏幕阅读器按照列的视觉顺序读内容而非 DOM 顺序——在 grid masonry 里不存在：屏幕阅读器按 DOM 顺序读，视觉上由浏览器填位，两个维度解耦。

渐进增强的落地路径

目前 Safari 最激进，26.4 默认开启；Chrome 需要 Chrome 121+（2024 年 3 月就进了稳定版）；Firefox 还在 flag 阶段，建议 chrome://flags 开启体验。生产环境推荐渐进增强写法：

/* 基线：column-count 方案， Safari/Firefox/Chrome 全支持 */
.card-grid {
  column-count: 3;
  column-gap: 1rem;
}
.card-grid > * {
  break-inside: avoid;
  margin-bottom: 1rem;
}

/* 增强：原生 masonry，三大引擎全上后覆盖 */
@supports (grid-template-rows: masonry) {
  .card-grid {
    column-count: unset;
    display: grid;
    grid-template-columns: repeat(3, 1fr);
    grid-template-rows: masonry;
    gap: 1rem;
  }
}

为什么这件事值得现在就开始迁移

腾讯云那篇 2026 年 CSS 特性横评里给过一组实测数据：100 张卡片的页面，首次渲染时间 Masonry.js 约 800ms（含重排），CSS Grid hack 约 500ms，原生 masonry 约 200ms。这不是边际优化——JS 库的初始化要经历 DOM 渲染 → JS 计算位置 → 强制同步重排这条链路，原生 masonry 等于把中间两步抹掉了。

更深层的改变是依赖本身的移除。Masonry.js 约 30KB（gzip 后），每次发版还要跟进安全更新；改用 CSS 之后这个依赖可以直接从 package.json 里删掉，CI 的漏洞扫描少一个告警项。

下一步：现在就检查你的瀑布流实现

打开 Chrome（121+）或者 Safari（26.4+），在 DevTools 控制台跑一句 CSS.supports("grid-template-rows", "masonry")，返回 true 的话就可以把现有实现切过去了。如果返回 false，先保持现有方案，等 Firefox 的 flag 放开再统一渐进增强。