要设计一个 Pinterest 风格的布局，开发者总是很累。不是累于构思设计，而是累于实现。许多开发者希望能用纯 CSS 实现瀑布流效果，不再依赖 JavaScript。但现实是，CSS 仍然没有完美的原生瀑布流解决方案。
这个问题已经引起了 CSS 工作组的重视。目前有三种竞争方案：扩展 CSS Grid 支持瀑布流、创建独立的 Masonry 模块，或者采纳 Apple WebKit 提出的统一系统 Item Flow。这三种方案各有利弊，而我们需要理解它们背后的设计理念。
当今 CSS 瀑布流的困境
瀑布流（Masonry Layout）是一种不规则的流动网格。与规则网格不同，瀑布流中的元素不会在短元素后方留下空隙，而是下一行的元素会上升填补这些空间。这种布局非常适合作品集、图片库和社交媒体信息流——那些需要有机流动的设计。
但遗憾的是，CSS 缺乏原生的瀑布流支持。开发者只能通过以下方式实现：
当前的 JavaScript 黑科技
最常见的做法是结合 CSS Grid 和 JavaScript，通过计算元素高度来动态设置跨度。代码看起来像这样：
.masonry-grid {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));
grid-auto-rows: 10px; /* 小行高用于精细跨度 */
grid-auto-flow: column;
gap: 10px;
}
.masonry-item {
overflow: hidden;
}
.masonry-item img {
width: 100%;
height: auto;
display: block;
}
然后使用 JavaScript 计算每个元素应该跨越的行数：
function applyMasonry() {
const grid = document.querySelector('.masonry-grid');
const items = grid.querySelectorAll('.masonry-item');
items.forEach(item => {
item.style.gridRowEnd = 'auto';
const rowHeight = 10;
const gap = 10;
const itemHeight = item.getBoundingClientRect().height;
const rowSpan = Math.ceil((itemHeight + gap) / (rowHeight + gap));
item.style.gridRowEnd = `span ${rowSpan}`;
});
}
window.addEventListener('load', applyMasonry);
window.addEventListener('resize', applyMasonry);
看起来可以工作，但问题很明显：
- 需要 JavaScript：这完全违背了"用 CSS 解决问题"的初心
- 性能问题：在复杂页面上，resize 事件触发的重新计算会导致卡顿
- DOM 顺序混乱：视觉流和逻辑 DOM 顺序可能不一致，影响无障碍访问
- 内容加载问题：当图片延迟加载或内容动态变化时，计算的跨度需要重新调整，容易造成布局抖动
其他方案的局限性
除了 Grid 黑科技外，开发者还会尝试：
- CSS Columns：虽然能创建多列效果，但无法精细控制元素流向
- Flexbox：本质上是一维布局，不适合二维瀑布流
- 第三方库（如 Masonry.js）：引入额外的依赖和体积
方案一：扩展 CSS Grid 支持瀑布流
CSS Grid Level 3 中有一个实验性提案：给 grid-template-rows 添加 masonry 值。目前只在 Firefox Nightly 中可用（需要启用标志）。
工作原理
.masonry-grid {
display: grid;
gap: 10px;
grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));
grid-template-rows: masonry; /* 关键：启用瀑布流模式 */
}
这样做的话，网格的列仍然保持为网格轴，而行则采用瀑布流模式。元素会沿着行逐个排列，尊重列的限制但不受行限制。
优势
- 熟悉的语法：建立在 Grid 已有的知识基础之上，学习曲线不陡
- 工具支持：Chrome DevTools 和 Firefox Inspector 都能很好地支持 Grid，无需 JavaScript hack
- 一致的心理模型：开发者不需要学习全新的布局系统
劣势
- 复杂性增加：Grid 的规范已经很庞大，加入 masonry 会让它变成一个"迷宫"。属性如
align-content、grid-auto-flow与 masonry 的交互还不明确 - 边界情况模糊：
- 元素跨越多列且要用瀑布流，会怎样？
- 不同列之间的间距不对齐，怎么办？
- 这些规范定义仍然不清楚
- 浏览器兼容性差：目前只有 Firefox Nightly 支持，即使有 polyfill 也无法在其他浏览器工作。这不是你想在客户项目中尝试的东西
- 实现 bug：早期测试显示，当内容动态加载时，元素会出现不可预测的跳跃，特别是在响应式设计中
开发者的批评
设计背景深厚的开发者对这个方案有意见：
- Rachel Andrew 指出：瀑布流的有机流动与 Grid 的严格二维结构相悖，可能会迷惑期望 Grid 表现的开发者
- Ahmad Shadeed 认为：这让 Grid 变得不必要地复杂，把两个完全不同的格式化上下文混在一起，这对教学和学习都是噩梦
方案二：独立的 Masonry 模块
另一个思路是创建一个全新的独立布局系统：display: masonry。这不是 Grid 的扩展，而是一个完全独立的模块。
工作原理
想象一个不依赖 Grid 的严格轨道或 Flexbox 的线性流动，而是专为垂直堆叠和水平调整设计的系统。目标是一个干净的新系统：
.masonry {
display: masonry;
masonry-direction: column;
gap: 1rem;
}
需要更多控制？假设的属性如 masonry-columns: auto 可以模仿 Grid 的 repeat(auto-fill, minmax())，而 masonry-align: balance 可能会平衡列长度以获得更精致的外观：
.gallery {
display: masonry;
masonry-columns: auto;
masonry-direction: column;
masonry-align: balance;
gap: 1.5rem;
}
优势
- 设计明确：模块专为瀑布流而生，不需要处理 Grid 的所有复杂性
- 心理模型清晰：Grid 用于有序排列，Flexbox 用于一维流动，Masonry 用于有机填充。三者各司其职
- 无需 JavaScript：真正的纯 CSS 解决方案，性能更好
- 响应式友好：内置对流动和自适应的支持，不需要手动计算
劣势
- 学习曲线：又是一个新的 CSS 模块，开发者要学新语法。CSS 已经够复杂了
- 浏览器采纳缓慢：推出新规范需要浏览器厂商的一致支持，这通常很慢
- 选择困惑：开发者会纠结"这个场景我应该用 Grid 还是 Masonry？"
- 规范还未成熟：早期讨论中存在许多未定的细节，实现可能需要多年
方案三：Item Flow 统一系统
2025 年 3 月，Apple WebKit 团队提出了 Item Flow，一个野心勃勃的新系统，试图统一 Flexbox、Grid 和 Masonry 的概念。
核心理念
与其在 Grid 中加入 masonry 或创建新模块，Item Flow 直接融合三者的优势。它引入了一个新的 item-flow 速记属性，替代 flex-flow 和 grid-auto-flow。
四个核心属性：
item-direction：控制流向（row、column、row-reverse、column-reverse）item-wrap：管理换行行为（wrap、nowrap、wrap-reverse）item-pack：决定打包密度（sparse、dense、balance）item-slack：调整容差，允许元素收缩或移位以适应
使用示例
用 Item Flow 实现瀑布流是一个自然的结果，不是硬加的功能：
.gallery {
display: grid; /* 或 flex */
item-flow: column wrap dense;
/* 长格式版本 */
item-direction: column;
item-wrap: wrap;
item-pack: dense;
gap: 1rem;
}
这里，元素垂直流动，包装成多列，并用 dense（密集）打包以最小化间隙。这模仿了瀑布流的有机排列。dense 选项受到 Grid 的 auto-flow: dense 启发，会重新排序元素以最小化空隙，而 item-slack 可以微调间距以获得视觉平衡。
优势
- 统一概念：Flexbox、Grid 和 Masonry 共享相同的基础属性，学习一次，用处处
- 增强现有系统：不是替代，而是增强。Grid 可以获得
nowrap，Flexbox 可以获得balance打包，这些都是长期需求 - 向后兼容：现有的
flex-flow和grid-auto-flow可以平滑地迁移 - 灵活性：
item-slack提供了微调空间，适应各种设计需求
劣势
- 未来功能：截至 2025 年 4 月，还没有浏览器实现 Item Flow。规范仍在讨论中，采纳时间不确定
- 命名问题：
item-slack等属性名称因clarity issue（特别是对非英语使用者）而面临命名辩论 - 社区接受度未知：这是一个全新的概念，能否得到浏览器厂商和开发者社区的支持还不明确
- 规范成熟度：CSS 工作组仍在收集反馈，最终形态可能会大幅变化
如何选择？
面对三种方案，开发者该如何是好？
| 方案 | 优点 | 缺点 | 现状 |
|---|---|---|---|
| Grid 扩展 | 熟悉、工具支持好 | 复杂、兼容性差、边界情况模糊 | Firefox Nightly 实验性 |
| 独立 Masonry | 设计清晰、专用 | 学习新语法、浏览器采纳慢 | 概念阶段，未实现 |
| Item Flow | 统一优雅、功能强大 | 尚未实现、命名有争议 | WebKit 提案，讨论中 |
现在的建议
短期（现在到 2026 年）：
- 如果必须实现瀑布流，使用经过验证的 JavaScript 库（如 Masonry.js）或 CSS Grid + JavaScript 组合
- 在 Firefox 上可以尝试
grid-template-rows: masonry，但不要用于生产环境
中期（2026-2027 年）：
- 关注 Item Flow 的发展。如果浏览器开始支持，这可能是最优选择
- 保持现有实现可维护，准备好迁移路径
长期：
- 一旦 Item Flow 在主流浏览器中支持，这将成为标准做法
- 或者如果独立 Masonry 模块最终胜出，准备学习新语法
实战建议
分析你的场景
- 瀑布流效果有多关键？
- 如果只是"看起来不错"，CSS Grid + 少量 JavaScript 足够
- 如果是核心用户体验，等等 Item Flow 或独立 Masonry
- 浏览器要求有多严格？
- 需要完美支持旧浏览器？只能用 JavaScript 库
- 可以要求现代浏览器？可以尝试 Grid 黑科技
- 性能有多重要？
- 内容多且频繁变化？等待原生 CSS 解决方案
- 内容相对固定？当前的 JavaScript 方案可接受
优化当前实现
如果你现在必须使用 JavaScript 解决方案，优化策略：
/* 使用 ResizeObserver 而不是 resize 事件，性能更好 */
const resizeObserver = new ResizeObserver(() => {
applyMasonry();
});
resizeObserver.observe(document.querySelector('.masonry-grid'));
/* 使用防抖减少计算频率 */
function debounce(fn, delay) {
let id;
return () => {
clearTimeout(id);
id = setTimeout(fn, delay);
};
}
window.addEventListener('resize', debounce(applyMasonry, 300));
/* 考虑虚拟滚动处理大列表 */
// 只在可视区域内计算和渲染元素
结论：等待还是行动？
CSS 瀑布流的故事还在书写。我们有三条路可走：
- 让 Grid 承载瀑布流——熟悉但有点笨重
- 创建专用 Masonry 模块——干净但陌生
- 用 Item Flow 统一一切——优雅但还要等
现在的现实是：没有完美的原生解决方案。但好消息是，这个问题正被重视，CSS 工作组和浏览器厂商在认真讨论。
我的建议：
- 如果项目不急，观察 Item Flow 的进展，这很可能成为最终赢家
- 如果必须现在实现，使用经过验证的 JavaScript 方案或库，并保持代码的可维护性，为未来的迁移做准备
- 参与讨论：在 CSS 工作组的 GitHub 问题中提供反馈，开发者的声音很重要
CSS 最终会给我们一个优雅的瀑布流解决方案。问题只是时间问题。