企业官网建设流程全解析

做前端的这些年，瀑布流布局需求就没断过。电商首页、图片素材站、文章卡片墙，到处都要那种高低错落、像水流一样铺开的视觉效果。放在以前，这活儿基本被 JavaScript 垄断，稍微复杂一点还得引个 Masonry 库，计算列高、维护数组、监听图片加载，折腾半天就为了把几张卡片摆整齐。但这两年 CSS 阵营悄悄把这块短板补上了，核心代码就三条样式，不需要任何脚本，纯静态页面也能直接上瀑布流。这篇文章就聊聊我实际使用中的思路、代码写法、适配细节和踩过的坑，给还在用 JS 做瀑布流的朋友一个减负方案。

1. 为什么 CSS 瀑布流“突然”能做了

1.1 传统 CSS 布局最大的心结：行高对齐

先说一个大家熟知的痛点。Flexbox 和 Grid 虽然强大，但本质上还是“行”的思想。一行里的元素默认在交叉轴上对齐，要么拉伸成一样高，要么顶部对齐，然后整行高度由最高的那个元素决定。瀑布流恰恰反着来——每张卡片高度随意，下面一行要继续往上补位，不能因为旁边卡片矮就留下一大片空白。

早期有人用 float 硬凑，效果很勉强。每列宽度固定，float 能勉强分成几列，可高度不齐的时候底部参差不齐，而且卡片顺序是横向走完一列才去下一列，跟真瀑布流的纵向阅读习惯差了十万八千里。用 Grid 也没好到哪去，标准 grid 模型每一行轨道高度一致，即使grid-auto-rows设成min-content，行内元素高度不一致时，finder 还是会按最高元素撑起整行，底部依然有空隙。说白了，传统 CSS 布局模型里缺少一种让元素“被填进最短那一列”的天然机制。

1.2 多列布局才是隐藏的主角

CSS 里其实一直藏着一套报刊排版专用的column多列布局。报纸分栏的时候，文章段落从上到下填满第一列，然后自动流到第二列，天然就是纵向填充的逻辑。瀑布流其实就是若干个“单列容器”并排放在一起，每列内部各自从上往下排列卡片，然后把不同高度的卡片均匀塞进各列——这不正是column天生擅长的活吗？

之所以以前没人把它当瀑布流用，一是早期 column 对破碎内容的控制太弱，卡片容易在列之间被硬生生切断；二是大家习惯了“JS Masonry 才是瀑布流正统”，没往这个方向想。直到这两年break-inside属性逐渐被浏览器稳定支持，卡片不截断了，列间距也能精细调节了，用三行 CSS 搭瀑布流才真正变得可用。我最早是在内部后台的卡片面板试水的，当天就把一个跑了两年的 JS 瀑布流页面重写了，效果直接对齐。

2. 三行核心代码实现纯 CSS 瀑布流

2.1 完整代码先摆出来

先放一个可以直接跑起来的最小示例。假设页面上有一堆.card，宽度不定、高度不定，图片撑开高度，内容多少也不统一，放进一个.masonry容器里：

<div class="masonry"> <div class="card"> <img src="1.jpg" alt=""> <p>这是第一张卡片的内容，高度自然撑开。</p> </div> <div class="card"> <img src="2.jpg" alt=""> <p>第二张卡片内容更长，在列内往下延伸。</p> </div> <!-- 更多卡片... --> </div>

.masonry { columns: 4; column-gap: 16px; } .card { break-inside: avoid; margin-bottom: 16px; }

严格来说，你真正需要用到的核心 CSS 规则就三条：columns: 4、column-gap: 16px、break-inside: avoid，第一行columns甚至能继续简写成column-count: 4。加上卡片底部间距，整个瀑布流就成了，零 JavaScript。浏览器渲染时自动计算每张卡片该进哪一列，哪列矮往哪填，顺序从上到下。实测在常规内容页里，几十张卡片的布局计算耗时可以忽略不计。

2.2 逐行拆解每条规则的意图

columns: 4看起来只是把容器平均分成四列，实际上它内部隐含了一个不太直观的逻辑：内容会优先填满第一列，再流向第二列，以此类推。也就是说，卡片在 DOM 里的排列顺序就是“第一列的从上到下，然后第二列的从上到下”，而不是第一行排完四张再排第二行。懂了这个方向，后面处理动态加载和数据顺序时就心里有数。

break-inside: avoid是最容易漏但最要命的一条。它的作用通俗讲就是“别把一张卡片拆成两半塞到两列里去”。没有这条规则，当卡片底部恰好落在列边界时，浏览器会把卡片内容拦腰截断，上半截在上一列，下半截跑下一列，页面直接没法看。这里多说一句，旧浏览器可能需要加-webkit-column-break-inside: avoid前缀才能生效，我在一些老的安卓 WebView 上确实遇到过，但现在主流浏览器直接用标准属性就够了。

column-gap负责列间距，那卡片上下间距怎么控制呢？我用的是margin-bottom，这是最稳的做法。你也可以给卡片套个内边距容器，或者在卡片内部再包一层统一间距，但会多一层 DOM。直接动用margin-bottom简单粗暴，而且因为每张卡片本身是独立的块级盒子，在瀑布流纵向排列时，margin正常生效，不会出现外边距折叠问题。

2.3 卡片内图片需要顺手处理的细节

卡片里只要放了图片，有几个小坑几乎必踩。第一是图片底部会出现一条四五像素的缝隙，这是图片作为内联元素留下的基线空隙，最常见的解法是让图片display: block，顺手加一句：

.card img { display: block; width: 100%; }

第二是图片还没加载完成时，卡片高度是 0，瀑布流看起来全是塌陷的方块。传统 JS 方案需要监听load事件然后重新排版，CSS 方案虽然也能在布局阶段拿到图片最终的占位尺寸吗？实际上columns布局遇到图片加载前后的高度变化是会自动回流重排的，因为浏览器在图片加载完成后会触发布局更新，但如果你希望规避加载闪动，可以在图片外层加一个固定宽高比的占位容器。现在也可以用aspect-ratio给图片设定宽高比，给容器卡位：

.card img { display: block; width: 100%; aspect-ratio: 4 / 3; object-fit: cover; }

aspect-ratio在图片还没加载时就会撑出比例空间，加载完成后高度不跳变。这个技巧在文章列表里的封面图上尤其好用，配合object-fit: cover，就算源图比例不统一，也不会把布局撑得乱七八糟。

3. 适配不同场景的进阶技巧

3.1 响应式列数：两种思路各有利弊

固定写死columns: 4在桌面端没问题，换成手机屏幕就太挤了。最简单粗暴的方式是加媒体查询，断点内写死不同的列数：

.masonry { columns: 1; } @media (min-width: 600px) { .masonry { columns: 2; } } @media (min-width: 900px) { .masonry { columns: 3; } } @media (min-width: 1200px) { .masonry { columns: 4; } }

这套写法直白，适合卡片宽度相对固定的场景。另一种思路是使用column-width：

.masonry { columns: 300px; }

这句的意思是“每列尽量 300px 宽，能塞几列就塞几列”，具体列数由浏览器根据容器宽度自动决定。比如 1000px 宽的容器，浏览器就排三列，多出的宽度分摊给列间距。这个方案响应式是天然实现的，不需要写任何媒体查询，移动端和桌面端都能自适应，缺点是你对列数失去精确控制，窄屏时可能出现两列、三列来回跳的情况。我个人的习惯是：页面结构固定的项目用column-count加断点，内容流特别复杂的用column-width图省事。

3.2 想要传统瀑布流的横向顺序怎么办

前面提过，CSS column 瀑布流默认是“纵向填充”顺序。如果图片流场景里你需要第一张图排在左上角、第二张排在第二列顶部这种“横向先走”的效果，纯 column 是做不到的。很多人第一次用的时候都会觉得顺序很别扭，因为 DOM 里的第 2 张卡片不一定会出现在右边的列，而是掉到第一列第二行。

如果你的产品需求不是严格的“时间倒序、最新图必须在最左上角”，其实纵向顺序影响不大。真遇到对顺序敏感的场景，我的经验是可以在数据层做一次“按列重排”——把数组按列数拆成几组，比如 4 列就把数据分成 4 组，第一组在前，第二组在后，间接实现横向顺序。但这会破坏“三行代码搞定”的初衷，所以建议一开始就评估清楚需求排序的重要程度。正经图片瀑布流 App 那种“加载更多后新图插到最顶上”的交互，用 CSS 方案基本无解，还是回去用 JS 靠谱。

3.3 动态加载更多内容时，布局会自动更新

用 JS 方案做“滚动到底部加载更多”时，需要手动调用masonry.layout()方法告诉库重新计算位置。CSS 方案不需要这一步——你把新节点追加到容器里，浏览器会自动把新卡片塞进当前最矮的列。这个特性在开发体验上属于降维打击，你只管拼字符串、插入节点，剩下的全是浏览器自己的渲染工作。

但有一点要注意：如果新卡片里还有图片，且图片没有占位尺寸，加载过程会触发布局抖动。列数少还看不出来，列数多的时候能明显看到卡片跳来跳去。我一般会给动态加载的卡片统一用 JS 生成一个aspect-ratio占位样式，或者直接约定封面图比例统一，从源头规避抖动。

3.4 空列问题与底部对齐处理

column布局在卡片数量不足时，可能出现最后一列空着，或者最后几张卡片分布得参差不齐、底部有很大的空白块。这个问题在 JS 方案里也不少见，因为每列高度天然不可能完全对齐。实用一点的兜底做法是：不要追求完美的底部平齐，瀑布流的美感本来就在错落；如果卡片量实在太少，可以适当减少列数，比如 2 列就比 4 列更容易让视觉显得饱满。还有一个小技巧，给容器设定一个最小高度（min-height），让少量卡片时布局也能撑满视觉区域，不至于显得特别空。

4. 和 JavaScript 方案的对比与选型建议

4.1 一张表格看清单方差异

看这张表就知道，这个对比不是“谁替代谁”，而是应用场景完全不同。纯粹的卡片展示页、图片墙、文章列表，用 CSS 方案就够了，少写代码，少维护一个库，页面还轻。但你要是做个后台编辑器，卡片需要拖拽排序、过滤筛选时带动画，或者一次加载几千条数据需要虚拟滚动，那 JS 方案依然不可替代。

4.2 加载性能与渲染性能谁更好

有朋友问过我，CSS 方案不也要浏览器自己去计算分列吗，和 JS 算有什么差别？差别大了。JS 方案里你要维护一个数组记录每列高度，每插入一张卡片都要遍历比较各列高度，然后通过transform或绝对定位把卡片塞进去，过程中可能触发多次强制回流。CSS 方案是浏览器渲染引擎里的布局模块直接处理，算法层面比脚本模拟高效得多，而且不需要手动监听图片加载。实测在 200 张卡片、开启性能面板的情况下，CSS 方案基本能做到布局不耗时，JS 方案在低端机上偶尔会看到白屏闪烁。

不过也别把 CSS 吹上天。如果你做的是电商那种“筛选品牌、排序价格”的交互页面，每次筛选结果变化时卡片列表整个重排，CSS 方案是做不到平滑动画的——因为列布局下元素位置由浏览器决定，你很难从 DOM 中精确知道每张卡片从哪列移到了哪列。此时还是乖乖用 JS 库做 FLIP 动画吧，视觉体验截然不同。

4.3 兼容性现状与降级策略

columns属性本身是 CSS 多列布局里的老成员，IE10 都认识它，浏览器支持层面没有大问题。真正决定是否能展示正常瀑布流的还是break-inside: avoid，它在 Chrome 85+、Firefox 60+、Safari 14+ 上都是标准行为，覆盖现役用户绰绰有余。如果你不得不兼容极其老旧的浏览器，降级策略也很简单：不用break-inside的话，卡片被拆分但布局还是有的，大不了视觉丑一点；或者用@supports判断一下，不支持的场景切回普通网格布局：

.masonry { display: grid; grid-template-columns: repeat(4, 1fr); gap: 16px; } @supports (columns: 4) and (break-inside: avoid) { .masonry { display: block; columns: 4; } .masonry .card { break-inside: avoid; } }

这样老浏览器走规整的四列网格，新浏览器走瀑布流，内容完整，不算好看但能用。

4.4 新特性展望：Grid 原生 Masonry

除了 column 方案，CSS Grid 也在草案阶段讨论过原生的 masonry 布局（grid-template-rows: masonry），能直接让 grid 子项目按瀑布流方式填充。Firefox 和 Chrome 都拿它做过原型，但至今还没有浏览器正式默认支持，日常项目里不建议等它。相比之下 column 方案现在是“即拿即用”的稳定选择，我自己的看法是，除非未来某天 gridding masonry 全面落地，否则目前动手项目优先选 column，不要被新特性吊着胃口。

5. 实操中常见的坑与排查技巧

5.1 卡片内容被拦腰截断

这是新手用 CSS 瀑布流遇到最多的 bug，表现形式是内容从一列串到另一列、文字从中间断开。原因只有一个：忘了写break-inside: avoid。有些时候写了但没生效，可以检查一下是不是被其他样式覆盖了，比如某些 CSS 框架里给块级元素加了break-inside: auto之类的规则。优先排查仍不行的话，给卡片套一个内层div，把break-inside: avoid加在内层上：

.card-inner { break-inside: avoid; }

这个方法做了层兜底，因为内外两层同时被截断的概率极低。

5.2 列数或列宽跟想象中不一样

使用了columns: 4却只显示三列？检查容器宽度是不是不够。如果卡片内部有固定最小宽度（比如一张 200px 的图片），浏览器为了保证卡片可读性可能自动减少列数。想强制列数的话，还要配合设置容器的总宽度，或者去掉卡片内部的固定宽度限制。反过来，卡片太宽导致一列都塞不下，也会出现布局崩坏，此时检查max-width优先于看 column 的锅。

5.3 卡片间出现莫名的间距不一致

CSS 瀑布流里卡片之间的垂直间距是margin-bottom，水平间距是column-gap，这两个值如果不一样，视觉上会横竖不均，看久了很难受。我建议把这两个值设成同一个 CSS 变量，比如：

:root { --masonry-gap: 16px; } .masonry { column-gap: var(--masonry-gap); } .card { margin-bottom: var(--masonry-gap); }

这样改一处，横竖间距同步变化，不会再出现“上间距 16 右边距 12”的尴尬情况。还有一点容易疏忽：column-gap也会影响卡片内部的多列文本，但瀑布流场景里卡片内部没有特殊列布局的时候不用操心。

5.4 容器高度异常或滚动条反复跳动

页面一开始就出现一个很高的空白块，然后图片一张张加载完才慢慢缩回去，这多半是图片没有占位尺寸，浏览器在图片加载前按 0 高度计算了整个瀑布流高度。前面提过用aspect-ratio能解决大部分场景，但有些动态图片地址拿不到比例，就无法预知占位高度。此时通用的补救方案是给图片标签加一行loading="lazy"，让浏览器按懒加载策略处理，配合 CSS 里给图片一个最小高度：

.card img { min-height: 120px; background: #f0f0f0; }

加载前至少有个灰块占位，加载完成后高度变化很小，视觉上不太突兀。

5.5 瀑布流容器最后一行左右明显不对称

有的页面看完所有卡片后，最后一列特别长，其他列都空了一大截。这通常是卡片总数和列数的整除关系导致的，不是 bug，是分布的自然结果。最简单的兜底方案是动态控制列数：卡片少的时候用 2 列，多了再撑到 4 列。纯 CSS 做不到按数量切换，需要写几行 JS 判断容器里卡片数量后动态设置类名。既然标题是“告别 JavaScript 布局”，这点小判断并不会拖累整体，加一个类名切换的成本几乎为零：

const container = document.querySelector('.masonry'); const count = container.children.length; container.classList.toggle('few-items', count < 8);

.masonry.few-items { columns: 2; }

这套组合方案在实际项目里既保住了 CSS 布局的简洁，又解决了极端数量下的观感问题。

5.6 动态加载后偶发卡片重叠

理论上浏览器会自动重排，但某些情况下（比如图片缓存、异步渲染顺序不同），动态插入节点时会短暂出现卡片重叠。这种现象大多是因为在同一个事件循环里同时插入了多个带图片的卡片，浏览器渲染时有中间态。我试下来最靠谱的解法是让每个新卡片先visibility: hidden，用动画帧推后两帧再显示：

.card-enter { visibility: hidden; }

requestAnimationFrame(() => { requestAnimationFrame(() => { card.classList.remove('card-enter'); }); });

这样给浏览器留出重排的余量，卡片出现时已经是稳定位置，不会闪烁，也不会重叠。这个技巧谈不上漂亮，但胜在稳定，是我在多列布局项目里长期使用的土办法。

最后分享一点个人体会

把瀑布流从 JS 换成 CSS 的这一年里，我最大的感受是：布局这事，能交给浏览器原生能力就别自己造轮子。CSS column 虽然是个老东西，但在合适的场景下，它比 Masonry 库更轻、更快、更省心。不过它也谈不上万能，遇到排序、过滤、动画这类强交互需求时照样得回头找 JavaScript。我给自己的选型标准很简单：纯展示型内容墙，无脑上 CSS；要频繁动元素位置，就老实接 JS 库，别两头硬凑。如果你正在维护一个沉重的 JS 瀑布流页面，不妨挑个不重要的模块试试这三行代码，实测一下性能提升，心里自然就有答案了。