纯CSS实现瀑布流：三行代码替代JavaScript复杂布局

做前端这么多年，“瀑布流”这词儿基本和JavaScript绑死了。以前不管你是用jQuery时代的Masonry.js，还是后来Vue/React项目里的各种虚拟滚动瀑布流组件，都得先引入一个不小的JS库，再等图片加载完算高度、算列数、做绝对定位，碰上数据一多还能卡掉帧。但这两年CSS终于补上了这门课，尤其最近看到不少项目已经在用原生属性实现瀑布流，效果还挺稳，最基础的核心代码甚至就三行，JS那套复杂的布局计算可以直接扔掉了。这篇就聊聊CSS瀑布流的实现思路、踩坑经验，以及未来真正的原生方案长什么样。

先说清楚：我这里的“CSS瀑布流”指的是纯样式层面解决多列不等高卡片的错位排列，不引入任何JavaScript计算。对大多数卡片流、图片流、商品列表、灵感采集类页面来说，这条路已经完全够用，而且渲染性能远好于早期用JS实时改top/left的做法。读完这篇，你应该能自己动手把旧项目的瀑布流改成纯CSS实现，也不再担心浏览器兼容性和布局抖动问题。

1. 瀑布流项目为什么绕不开CSS化

1.1 老方案的核心痛点是高度计算

瀑布流布局的难点在于：卡片高度不一致，又希望它们像水流一样自然填充纵向空白。传统实现思路大致是让JavaScript读取每张卡片的实际高度，然后按最短列优先原则，用绝对定位把卡片塞到对应坐标上。听起来不难，但实际操作时会遇到一堆问题。

图片没有固定宽高比时，必须在图片加载完成后才能算出准确高度，一旦异步加载，就得触发重排重算；用户窗口宽度变化时，列数变了，又得重新跑一遍算法；如果用虚拟滚动，还要处理滚动位置映射。代码越写越复杂，调试成本直线上升。更难受的是，这种JS布局方式会让浏览器频繁触发layout和paint，卡片一多，滚动体验就会发黏。

所以很多团队一直在等浏览器原生支持。CSS其实早就有了columns多列布局，但早年大家担心它把内容按列均分，顺序会从左往右垂直排而不是常见的从左往右横向排，所以在瀑布流场景里用得不多。直到大家发现“只要把内容高度撑开，列内强制定位，顺序问题其实可以通过数据重排解决”，columns方案才重新被重视起来。

1.2 三行代码方案的原理和适用边界

这里说的是最基础的CSS多列瀑布流，核心代码确实就三行：

css复制.masonry {
  columns: 3 18rem;
  column-gap: 1.5rem;
}
.masonry-item {
  break-inside: avoid;
  margin-bottom: 1.5rem;
}

.masonry设置列数和列宽，.masonry-item防止单个卡片被截断到两列之间。就这两条规则，加一个容器class，整个页面就变成瀑布流了。相比JS方案动辄几十行逻辑加事件监听，这个确实属于“三行代码搞定”的范畴。

但要说清楚：这不是真正的“原生瀑布流”，本质是多列布局。浏览器会优先把文档流竖向填满第一列，再进入第二列，跟我们习惯的“先左后右、横向逐行”顺序不一样。如果你的卡片数据来自接口，渲染顺序又是线性渲染，那用户看到的排列顺序会是纵向的。解决办法也简单：把数据手动切分成三组，分别塞进三个容器，然后用flex横排，每个容器内部都是普通纵向文档流，这样既保留了多列的高度自适应，又还原了从左到右的阅读顺序。这个技巧后面详细说。

这套方案最适合图片卡、文章卡这种“整块不可拆分”的内容。对于纯文本或需要跨列展示的元素，直接用columns会有些局限。

2. 从零搭一个纯CSS瀑布流页面

2.1 HTML结构设计与关键CSS属性拆解

我以灵感采集页面为例，做一套带封面图、标题和标签的卡片。HTML结构大概是：

html复制<div class="masonry" id="masonry">
  <article class="card">
    <img src="cover1.jpg" alt="卡片封面" />
    <div class="card-body">
      <h3>卡片标题</h3>
      <p>卡片摘要描述文字，长度可变，用来模拟不同高度。</p>
      <span class="tag">#CSS</span>
    </div>
  </article>
  <!-- 更多卡片 -->
</div>

CSS部分，我建议不要只写三行，而是拆成几组配置，方便维护：

css复制.masonry {
  columns: 4 20rem;
  column-gap: 1.5rem;
}

.card {
  break-inside: avoid;
  margin-bottom: 1.5rem;
  border-radius: 12px;
  overflow: hidden;
  background: #fff;
  box-shadow: 0 2px 8px rgba(0, 0, 0, 0.06);
}

columns: 4 20rem是column-count: 4和column-width: 20rem的简写，意思是“每列至少20rem宽，能放下几列就放几列”。只写一个columns: 4就直接固定成四列，不管屏幕宽度怎么变都是四列，适合内容管理系统后台；写20rem这种列宽值，则能自动响应式地调整列数。两者各有使用场景，后者更适合面向访客的展示页面。

break-inside: avoid这句必须加，否则浏览器会把一个卡片从中间劈开，上半截在上一列底部，下半截在下一列顶部，视觉上直接裂开。类似地还有page-break-inside和break-inside: avoid-column，不过现在标准属性直接用break-inside就够，老项目里如果看到page-break-inside，也能理解，那是旧语法兼容写法。

2.2 自适应列数与卡片间距的调优技巧

理想状态下，卡片宽度应该跟着屏幕走，而不是写死。用columns: 4 20rem之后，窗口宽度在1200px时一般是四列，在800px时就自动变成三列甚至两列，这个自动换列是由列宽约束推导的，不需要媒体查询。但这种推导有它的脾气——如果容器宽度恰好是列宽的三倍还多一点，但也达不到四倍，最后一列会显得特别宽，卡片被拉伸，观感不好。

我一般这样调整：给容器加一个max-width限制内容区最大宽度，然后让列宽尽量整除内容区宽度，避免出现半列。比如内容区最大1240px，减去3个1.5rem的间距后，每列约386px，那columns: 3 24rem就能稳定出三列，不会出现尴尬的分列。

如果你希望列数完全可控，同时享受响应式，也可以直接这样组合：

css复制.masonry {
  columns: 3;
  column-gap: 1.5rem;
}

@media (max-width: 900px) {
  .masonry {
    columns: 2;
  }
}

@media (max-width: 600px) {
  .masonry {
    columns: 1;
  }
}

这种做法更直白，也更容易排查问题。团队协作时，其他同事看到columns: 3就知道是固定三列，不用去推算20rem在不同屏幕下的实际效果。

卡片内边距和图片宽度也要注意表现一致性。图片建议设置width: 100%，高度自适应，否则不同图片在卡片里显示宽度不一致；display: block也要加上，避免图片底部的inline空白缝隙让间距显得不均匀。

3. 进一步提升：从多列布局到真·瀑布流方案

3.1 多列布局的坑：数据纵向排序怎么办

多列布局最大的争议是排列顺序。我打个比方：手拿一叠扑克牌，想要按花色横着发四列，结果一张张往桌上叠，第一列叠了十几张才开始第二列——这种纵向顺序在瀑布流场景里会让“按时间倒序”的内容观感很奇怪，用户会觉得最新内容全在左列，右边都是旧内容。

解决办法之一是手动分组。假设接口返回一个数组list，你期望按时间倒序横向排列，那么在前端做数据分片：

javascript复制const chunkSize = Math.ceil(list.length / 3);
const columns = [list.slice(0, chunkSize), list.slice(chunkSize, chunkSize * 2), list.slice(chunkSize * 2)];

然后渲染成三个并排的容器，每个容器内部用display: flex; flex-direction: column纵向排列卡片。这样页面上看是三列瀑布流，但实际是三个独立的纵向流，顺序保持从左到右、再从上到下。代价是卡片高度不均时，列与列底部会参差，视觉上接近瀑布流，但不能自动把新卡片插到最短列底部。

如果你能接受“按列填充”的顺序，那直接一个.masonry容器就行，代码最简单。具体选择取决于业务：图片流、灵感流这种高度差距大、排序不重要的场景，直接多列布局很合适；新闻流、商品列表这种强依赖时间序或价格序的，建议用分组方案或Grid方案。

3.2 原生masonry：grid-template-rows的进击与兼容现状

CSS Grid在2020年前后已经成了布局主流，但真正的瀑布流属性其实还在路上，名字叫CSS Masonry Layout。它通过在grid容器上写一行：

css复制.masonry {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(240px, 1fr));
  grid-template-rows: masonry;
}

就能实现真正的瀑布流：网格自动把高度不同的条目填到最短列，保持横向顺序。这个方案的想象空间很大，因为它是grid体系的扩展，可以配合grid-column、grid-row做跨列跨行，也能完美处理排序。但现实是，这个属性在Chrome中曾以试验特性出现过，后来又被移除，目前只有Firefox在实验性标志后面支持。也就是说，现阶段直接在生产环境使用grid-template-rows: masonry还太激进，需要做好功能降级。

我的建议是：把它当作渐进增强方案。先写一套columns多列布局作为基础样式，再检测浏览器是否支持masonry，支持的话升级为grid masonry：

css复制@supports (grid-template-rows: masonry) {
  .masonry {
    display: grid;
    grid-template-columns: repeat(auto-fill, minmax(240px, 1fr));
    grid-template-rows: masonry;
  }
}

这样既能让新版Firefox用户享受真正瀑布流，又不影响其他浏览器的展示。等Chrome和Safari正式跟进后，直接把columns那段删掉即可。从目前W3C的进度来看，这个属性正在走向标准化，但具体发布时间还不能确定。

3.3 Grid模拟瀑布流的另一条路

在等待原生masonry普及之前，如果你项目里已经重度使用Grid，还有一种折中方案：用grid-auto-rows配合row-span模拟瀑布流。大概思路是给每张卡片设置一个比内容略大的行高倍数，比如：

css复制.grid-masonry {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  grid-auto-rows: 8px;
}

.card:nth-child(1) { grid-row: span 20; }
.card:nth-child(2) { grid-row: span 24; }
.card:nth-child(3) { grid-row: span 18; }

这种方案要求你知道或者能估算每张卡片的高度，纯静态页面可以直接用，但动态数据一多就很难维护。有些库用JS去计算每个卡片高度然后动态设置grid-row: span，那又绕回了JS计算的老路，性能收益有限。所以我个人只在固定模板的小型场景里用。

4. 踩坑实录与常见问题排查

4.1 图片加载导致卡片裂开或高度跳动

用columns布局时，最典型的坑是卡片裂开。明明加了break-inside: avoid，但还有些卡片在刷新时裂成两半。查下来往往是因为图片还没加载完，浏览器先以占位高度计算列分布，图片到位后高度变了，导致原来的断点位置失效。

解决思路有几种。第一种是给图片容器设置固定高度比，比如统一用aspect-ratio: 16 / 10占位，图片用object-fit: cover填充，这样哪怕图片加载前，卡片高度也是确定的，浏览器可以稳定计算断点。第二种是给卡片设一个最小高度，减小裂开概率。第三种是配合懒加载，只对首屏可见的卡片做渲染，避免一次性加载几百张图导致重排风暴。

我还遇到过另一种情况：图片是懒加载的，滚动到下方时新图加载完，上方列的底部突然多出一截，视觉上像整列往下跳了一下。这种情况通常是卡片用了margin-bottom，但图片加载后撑高了卡片，列高变化导致后续卡片整体移动。如果想彻底避免，最有效的方式是保证卡片高度恒定，具体做法就是前面说的统一比例占位。

4.2 break-inside的兼容性写法

break-inside: avoid虽然标准，但在老版浏览器里，有时还需要补一个page-break-inside: avoid。这俩一个是新版CSS Fragmentation属性，一个是老版分页属性。好消息是，我接触到的浏览器中，包括旧版Edge和移动端主流浏览器，对新属性支持度都不错，写一行就够。如果你的站点还要兼容IE11，那columns方案大概率不能直接用，因为IE11对多列布局的支持很不完整，建议换个思路。

另外注意，break-inside: avoid对普通块级元素生效，但不要给break容器内部的flex子元素设置break-inside。我踩过的坑是，卡片里用了flex布局展示图片加文字，flex子元素自身的break行为会受flex容器影响，有时候控制不住。稳妥做法是让卡片根节点就是break容器，内部随意flex，不影响整体。

4.3 滚动性能：为什么比JS方案更香

很多人担心CSS瀑布流滚动时会不会卡，实测下来，columns方案在渲染上千张卡片时比早年JS绝对定位的方案要流畅不少。原因在于浏览器对多列布局的渲染是分块进行的，列之间的协调成本远低于JS不断修改top/left带来的布局抖动。而且没有JS监听滚动事件，也就没有频繁的getBoundingClientRect调用，主线程占用明显降低。

当然，如果是十万条数据级的长列表，纯CSS渲染依然会有压力。这跟任何布局方式都逃不开DOM节点数量的问题有关。我的建议是配一个IntersectionObserver做无限滚动，只渲染当前视口附近的数据，而不是一次性把十万个DOM节点全部扔进去。很多人对“CSS三行代码”有误解，以为从此什么都不用管了，其实CSS替换的只是布局算法部分，数据加载和虚拟化依然需要前端自己控制。

4.4 常见问题速查表

这个表格是我做项目时自己常查的清单。遇到问题先看现象，再定位原因，能少走不少弯路。

5. 从瀑布流到流式布局：关于CSS布局选择的个人体会

做了一段时间CSS瀑布流之后，我发现它本质上是一个“流式布局”问题，和早年的flex布局、grid布局演进路线一脉相承。以前我们为了做等宽卡片列表，不得不把所有元素塞进flex容器里，flex虽然能解决单行或单列的对齐，却无法处理不等高元素的自动补位；grid解决了二维对齐问题，但真正的masonry属性还没完全落地；columns则用最简单的属性实现了“视觉上像瀑布流”的近似效果。

有人问我说，会不会再过两年，CSS瀑布流属性普及后，这些替代方案就全没用了？我的看法是：不同的方案服务于不同的数据形态。如果你只是做一个图片采集墙，columns方案永远够用，而且它有清晰的分页语义；如果数据带复杂排序、需要跨列展示，原生masonry和grid的组合会更顺手。工具永远在进化，关键是理解每种方案的适用边界。

最后分享一个自己常在项目中用的组合：内容量少、排序不敏感时直接用columns；内容量中等、要横向阅读顺序时用数据分组加flex列；内容量大、强依赖滚动加载时用columns加IntersectionObserver懒加载，同时在支持masonry的浏览器上升级为grid masonry。这套思路我在个人博客和两个商业项目里都验证过，踩坑最少，维护成本最低。

如果你现在正要改造一个旧项目，我的建议是别急着全部重写。先在页面最外层套一个columns容器，跑一下性能面板，看看首屏渲染时间有没有变化，滚动时有没有明显的布局抖动。只要浏览器支持现代CSS，这个改动基本是无痛的。真遇到奇怪的兼容问题，回头看这篇的排查表，八成能找到答案。