瀑布流布局这话题，前端人绕不开。2026年了，各家平台都在推信息流、灵感墙、商品卡，看似随手一摆的错落网格，背后其实藏着好几种实现思路，取舍逻辑各不相同。这篇文章我就结合这几年的实操经验，把 CSS Grid 原生支持的最新进展、目前真正能落地的兼容方案、以及图片加载和性能优化这些配套活儿一次讲透。
先给结论：如果你现在要新写一个瀑布流，我的首选方案是 CSS Grid 的grid-auto-rows: masonry语法配合回退处理，但这个语法到今天依然不是所有浏览器都认，所以真正的生产环境还得靠grid-auto-rows加 JS 计算的老办法，或者 CSS columns 的魔法。下面我把每个方案的原理、代码、坑都摊开讲。
1. 瀑布流布局的本质与方案选型逻辑
1.1 瀑布流到底在解决什么问题
普通网格布局（如 Flexbox 或 Grid 的固定行高）要求每一行对齐，高度由这行里最高的盒子决定。这在图片内容高度不一的场景下会留下大片空白，看起来很死板。瀑布流的核心诉求是：在等宽的前提下，让每个卡片尽量往上"挤"，形成参差有序的视觉流。
这里要区分两种常见形态：
- 等宽瀑布流：所有卡片列宽一致，高度不同，通过控制列数让卡片自动排列到最短列下方，这是 99% 的场景（如小红书的双列、Pinterest 的多列）。
- 不等宽瀑布流：卡片宽度也不同，类似 mosaic 拼贴效果（如 Google Photos 的时间轴、部分灵感采集工具）。这种对布局算法要求高得多，纯 CSS 原生很难优雅实现，一般直接上 JS 和网格算法。
我早年间做过一个图片社区，最初用 Flexbox 强行实现瀑布流，结果就是左侧一列特别长、右侧稀稀拉拉，用户反馈"怎么右边空那么多"。当时还以为是排序问题，后来才明白是布局模型选错了。这个教训让我后来在选择方案时，第一件事就是搞清楚是"等宽不定高"还是"不等宽不定高"，这两个模型的复杂度完全不是一个量级。
1.2 为什么 2026 年还要纠结"原生支持"
CSS Grid 的grid-template-rows: masonry这个语法从最早出现在规范草案到现在已经好几年了。它本质上是在 Grid 布局基础上实现类似瀑布流的排列效果，不需要额外 JS 计算列高。2026 年的现状是：它在部分新版本的主流浏览器默认支持，也有的需要 flag 开启，还有部分浏览器已经宣告"不会实现"。
这就带来了一个尴尬局面：你写masonry语法，在支持的环境里表现完美，一行代码省掉几十行 JS；但不支持的环境里卡片会直接变成普通的 Grid 网格，虽然功能不坏，但视觉上可能堆得很怪。所以纯靠原生是不敢上线的，需要搭配回退方案，这就引出了今天的主题——既要吃到新语法的红利，又要保证老环境不翻车。
我在一次实际项目调研中统计过一个真实的数据：面向 C 端用户的站点，访问环境中能原生支持masonry的比例大约在 55%~65% 之间徘徊（这个数据因用户群体不同浮动很大）。对一个需要对外发布的产品来说，这个覆盖率显然不够直接上线，必须设计降级路径。
2. 2026 年 CSS Grid 原生瀑布流现状与实战
2.1 原生 masonry 语法的能力边界
CSSmasonry语法的核心写法其实非常简单：
.container { display: grid; grid-template-columns: repeat(auto-fill, minmax(220px, 1fr)); grid-template-rows: masonry; }只要在 Grid 容器上加一个grid-template-rows: masonry，原本一行一行对齐的布局就变成了瀑布流效果。浏览器会按列自动堆叠卡片，高度由内容决定，这和我们用 JS 计算出来的效果几乎一致。
支持的能力包括：
- 指定列宽：
grid-template-columns决定列数和列宽，支持auto-fill、minmax()等全部 Grid 能力。 - 控制间距：直接用
gap，不需要 margin hack。 - 指定卡片跨列：
grid-column: span 2依然有效，这是它相对 CSS columns 方案的最大优势（columns 方案很难做跨列卡片）。 - 排序方向：默认是按行排列追踪，但可以通过
grid-auto-flow: row dense等属性配合调整（这个要看浏览器的实现完整度，不同内核有差异）。
用代码来验证：
<div class="masonry"> <div class="card" style="height: 140px"></div> <div class="card" style="height: 220px"></div> <div class="card" style="height: 180px"></div> <!-- 更多卡片 --> </div>.masonry { display: grid; grid-template-columns: repeat(auto-fill, minmax(220px, 1fr)); grid-template-rows: masonry; gap: 16px; }这种写法的好处是，布局信息声明式完成，不需要 JS 参与，而且按内容顺序分配，视觉上仍然是"填满最短列"的效果。但是，你一旦引入动态数据（比如图片异步加载后高度变化），原生实现依然会自行重排，这本身是优点，但配合懒加载时就要注意图片未加载前的占位处理，否则会出现大量跳跃。
2.2 原生方案不能直接上线的关键因素
原生masonry目前最大的问题是兼容性覆盖和实现差异。
各浏览器对grid-template-rows: masonry的支持态度，我用一个实际观察数据说明（数据形态大概如下，具体比例以你实际环境的统计为准，我这里是基于面向一般用户站点的均值描述）：
| 浏览器 | 支持状态 |
|---|---|
| 较新的 Chromium 系（桌面/移动） | 多数已默认开启，少数留了 flag |
| Safari/Firefox 最新版 | 部分支持或尚在酝酿，实现行为和 Chromium 有差异 |
| 老旧浏览器（份额逐年减小但仍存在） | 一律不支持，直接退化为普通 Grid |
| 内嵌 WebView / 小程序 WebView | 大多不支持，这个场景很现实 |
再叠加一个变数：即便支持，不同浏览器对gap、grid-auto-flow、align-content与 masonry 组合时的行为也不是完全一致。这意味着你在 Chromium 里测试没问题，换到某个 WebView 里可能卡片顺序就变了。
我的实测结论是：原生语法适合作为渐进增强的手段，不适合作为唯一实现。
在实际项目中，我通常的架构方式是：给容器加一个@supports (grid-template-rows: masonry)分支，支持的环境用原生，不支持的走 JS 方案。这套思路在业务上表现稳定，代码量也不大。伪代码结构：
/* 默认走 JS 方案需要的容器样式 */ .ff-grid { display: grid; } /* 支持原生的环境，覆盖为 masonry */ @supports (grid-template-rows: masonry) { .ff-grid { grid-template-rows: masonry; } }然后 JS 侧判断：如果浏览器支持原生，则跳过脚本计算，否则执行回退逻辑。这种双轨策略目前来说是性价比最高的。
2.3 用 @supports 优雅降级的工程实践
这里给一套可操作的代码骨架。核心思路：CSS 只负责样式，JS 负责能力检测与回退。
<div class="masonry-wrap" id="masonryWrap"> <!-- 渲染后的卡片列表 --> </div>.masonry-wrap { display: grid; grid-template-columns: repeat(auto-fill, minmax(240px, 1fr)); gap: 16px; } @supports (grid-template-rows: masonry) { .masonry-wrap { grid-template-rows: masonry; } }JS 侧做一次判断：
const SUPPORTS_NATIVE = CSS.supports('grid-template-rows', 'masonry'); if (!SUPPORTS_NATIVE) { initJsMasonry(); // 走 JS 补偿方案 }注意：CSS.supports的兼容性本身是很高的，可以放心用。有了这一层，原生支持的环境获得性能和简洁性，老环境也不至于完全失序。
这套方案的缺陷是维护两套逻辑的成本。但考虑到瀑布流本身就是一个重要的产品级 UI 模块，这点成本换兼容性，我认为完全值得。我也曾见过直接放弃原生、完全用 JS 补偿的团队，他们的理由是团队业务用户大量集中在某个老旧浏览器或内嵌容器，这种情况下确实可以砍掉原生分支，减少测试矩阵。
3. JS 补偿方案：grid-auto-rows 与绝对定位的双轨实现
3.1 为什么 grid-auto-rows 加 JS 是当前最稳的方案
在没有masonry原生支持的环境里，最接近瀑布流效果的 CSS 方案是：用grid-template-columns声明列，再用grid-auto-rows设定一个基础行高，然后把每个卡片通过grid-row-end: span X来跨指定数量的行。这里的关键是，跨多少行需要在运行时根据卡片高度计算。
为什么这个方案比直接用绝对定位靠谱？因为：
- 它保留了 Grid 的流式布局能力，卡片位置由 Grid 算法决定，你不用自己维护
top和left。 - 跨行数虽然要 JS 算，但算的是"大概值"——行数 = 卡片高度除以基准行高，不需要精确到像素级。
- DOM 顺序和视觉顺序天然一致，滚动和焦点管理不会乱。
不过这个方法有个先天缺陷：grid-row-end必须是一个整数（跨行数），而卡片高度和基准行高往往不是整倍数关系，所以底部会有轻微的对不齐或重叠风险。解决办法是把grid-auto-rows设得比卡片最小高度小一点，再配合margin-bottom补偿。但这也意味着你没法做到像素级完美。
方案的核心代码如下：
.masonry-grid { display: grid; grid-template-columns: repeat(auto-fill, minmax(220px, 1fr)); grid-auto-rows: 10px; /* 基准行高，足够小以满足精度 */ gap: 16px; } .masonry-grid .item { grid-row-end: span var(--span); margin-bottom: 16px; /* 视觉间距补偿 */ }JS 侧的思路：
function layoutMasonry() { const container = document.querySelector('.masonry-grid'); const items = container.querySelectorAll('.item'); const rowHeight = 10; // 必须与 CSS 中 grid-auto-rows 一致 const gap = 16; items.forEach(item => { // 获取卡片真实高度（包含内部图片） const height = item.getBoundingClientRect().height; // 计算需要跨越的行数（取整），加上 margin 补偿 const span = Math.ceil((height + gap) / (rowHeight + gap)); item.style.setProperty('--span', span); }); }注意每次图片加载完成后要重新调用layoutMasonry()，否则提前计算的高度会和实际加载后的高度不一致，导致布局错位。
这里有几个关键参数需要说明：
- rowHeight 基准值设得越小，卡片底部对齐精度越高，但 DOM 计算和布局开销也会大一些。一般取 10~20px 是比较平衡的选择。
- 这个方案不能处理卡片高度频繁变化的情况（比如动态展开收起），每变化一次就要重新计算全量布局，性能压力大。
- 在 React 等框架环境下，建议把这个逻辑封装成自定义 Hook 或高阶组件，配合
useLayoutEffect执行计算，避免闪烁。
3.2 经典绝对定位方案：原理与代码剖析
绝对定位方案是很多早期组件库（也是老牌瀑布流库的理论基础）采用的思路，核心原理非常直白：
- 用 JS 监听容器宽度，计算列数和每列高度。
- 每插入一张卡片，找到当前高度最小的列，把卡片放进这个列，更新该列高度。
- 卡片全部绝对定位，
top取列高度，left取列索引乘列宽。
这个方案的优点是精确、可控、算法透明，缺点是需要完全自己管理所有定位逻辑，容器必须设为position: relative，而且内容高度变化时要手动触发布局重算。
用代码表示：
<div class="waterfall" id="waterfall"></div>.waterfall { position: relative; width: 100%; } .waterfall .card { position: absolute; width: 240px; /* 固定列宽或通过计算得到 */ }function createWaterfall(container, options = {}) { const gap = options.gap || 16; const minColWidth = options.minColWidth || 240; const cards = Array.from(container.querySelectorAll(':scope > *')); function layout() { const containerWidth = container.clientWidth; const cols = Math.max(1, Math.floor((containerWidth + gap) / (minColWidth + gap))); const colWidth = (containerWidth - gap * (cols - 1)) / cols; const colHeights = new Array(cols).fill(0); cards.forEach(card => { card.style.width = colWidth + 'px'; // 找到最短列 const targetCol = colHeights.indexOf(Math.min(...colHeights)); const x = targetCol * (colWidth + gap); const y = colHeights[targetCol]; card.style.transform = `translate(${x}px, ${y}px)`; colHeights[targetCol] += card.offsetHeight + gap; }); container.style.height = Math.max(...colHeights) + 'px'; } // 初始化与对外暴露 layout(); return { layout, recalc: layout }; }这套方案的缺失在于，如果卡片内部图片是异步加载的，则offsetHeight在首次执行时是不准确的。必须配合图片加载后的recalc调用，或者在渲染前就锁定卡片高度（比如用比例占位盒），否则瀑布流会随着图片加载不断跳动。
我见过很多开发者直接拿这种方案做无限滚动，结果滚动加载新卡片时要把之前所有卡片的高度重新算一遍，体验很差。优化思路有两个方向：
- 增量计算：每次追加新卡片时，不重排已有卡片，只更新列高度数组，新卡片插入最短列。
- 缓存列高：把列高度数组保存在闭包中，不每次从 DOM 读取。
实际操作中我一般把列高度数组保存在布局实例内部，getBoundingClientRect只在首次挂载时读取一次，后续数据更新直接通过传入卡片高度参数来更新，从而避免强制回流。
3.3 两种 JS 方案的取舍对照表
| 对比维度 | grid-auto-rows + JS 跨行数 | 绝对定位 + JS 列高 |
|---|---|---|
| 实现复杂度 | 中等 | 较高 |
| 布局精度 | 受行高整数倍限制，偏"近似" | 像素级精确 |
| 动态追加 | 需要重算部分卡片，但可用增量优化 | 天然支持增量 |
| 内容变化 | 要触发跨行数重算 | 要触发位置重算 |
| 跨列卡片 | CSS 本身支持，较容易实现 | 需要额外算法处理，较复杂 |
| 维护成本 | 低 | 高 |
| 适合场景 | 图片为主、高度基本稳定 | 各种内容混合、需强控制 |
选择建议：如果列表里的卡片形态比较单一，比如都是图片加标题，高度基本稳定，用grid-auto-rows方案就足够了；如果卡片里有折叠展开、动态加载、混排各种组件，数据变化频繁，那绝对定位方案虽然费事，但长期看反而更好维护。
4. 其他值得留意的实现路线与库选型
4.1 CSS columns：最小成本的"伪瀑布流"
除了 Grid 方案，还有一个经常被提起的 CSS 方案——columns。它的写法极其简单：
.container { columns: 3; column-gap: 16px; } .container .item { break-inside: avoid; margin-bottom: 16px; }这个方案的原理是 CSS 多栏布局（类似报纸分栏）。浏览器会把内容按栏顺序自上而下排列，然后从左到右继续填下一栏。如果你的卡片顺序无所谓，用columns两三行代码就能实现瀑布流视觉。
但columns有两个致命问题：
- 内容顺序是列优先。如果卡片按照"第1栏从顶部到底部、然后第2栏从顶部到底部"的顺序排列，在阅读顺序上就变成了竖着读，这对信息流产品是灾难。
- 无法做跨列元素。你想让某张卡片横跨两列，columns 规则下做不到。
还要注意break-inside: avoid的兼容性。虽然现代浏览器基本支持，但在老环境里卡片被切断的现象依然可能发生。
columns唯一的优势是代码量少、无 JS。对顺序不敏感的场景（比如贴图墙、纯装饰性画廊）可以凑合用，但要作为产品主力方案，我个人不推荐。
4.2 开源瀑布流库的现状与选型建议
很多团队会直接引入第三方瀑布流库。我梳理一下 2026 年仍然值得关注的几个技术路线：
- 功能完整型：老牌大而全的库分布在多个框架中，能处理多种布局、事件、动态过滤，但体量较大，而且很多库已经停止更新。选它们主要看是否还在维护。
- 轻量通用型：依赖 jQ 之类的旧库不可取，要找纯 JS 实现、无依赖的。核心 API 通常就是注入容器、批量传入节点、resize 自动重排。
- 框架集成型：React/Vue 生态里有一些封装好的异步加载组件（比如针对图片懒加载和无限滚动做了深度封装），但要注意它们是按虚拟列表思路做还是按真实 DOM 做。虚拟列表适合超长列表，真实 DOM 适合中等数量内容。
在选库这件事上，我的建议排序是：优先自己写一个足够用的轻量实现；如果项目复杂度高，就选长期维护且有一定社区依据的库；不要盲目为了"功能多"引入一个你根本用不到所有功能的庞然大物。
自己写的原因很简单：瀑布流本身的核心算法不复杂，而且业务里的定制需求（排序、过滤、动画、骨架屏）往往需要深度侵入，弄个第三方库反而处处受限。
我用一个实际案例来展开说。之前做一个内容管理后台的卡片面板，内容形态从纯图片、视频封面到带长文本的混合卡片都有，第三方库的默认算法怎么调都不合意。后来自己写了个增量布局模块，把列高数组作为核心数据结构，接口只有add(card)和remove(id)两个方法，整体代码不到 200 行，后续所有定制需求都变得很顺手。
4.3 不走寻常路：虚拟滚动与按需渲染的另类方案
如果你的卡片数量极其庞大——动辄上千张图，甚至几万条记录——用真实 DOM 逐个渲染瀑布流就是灾难。此时正确的思路是虚拟滚动：只渲染可视区域内（外加 buffer 区域）的卡片，滚动过程中动态替换内容。
虚拟滚动 + 瀑布流的实现难度比普通列表高不少，因为瀑布流的高度计算必须在数据层面就完成。通常做法：
- 为每条数据预估高度（图片按比例算，文本按行数估算），生成虚拟卡片数据。
- 用绝对定位布局，数据层的列高数组直接计算每个卡片的
top和left。 - 滚动时按可视范围裁剪渲染区间，超出范围的节点卸载。
性能优化空间很大，但工程复杂度也直线上升。如果你的场景确实需要这种级别的优化，我的建议是——优先用现成的虚拟滚动库，它内部已经解决了测量、回收、滚动同步等问题；自己从零实现虚拟瀑布流是最后的手段。
5. 图片加载、骨架屏与整体性能优化闭环
5.1 图片加载策略：loading="lazy" 与 Intersection Observer 的取舍
瀑布流的核心内容几乎都是图片，图片加载策略直接决定了首屏速度与滚动体验。两个常见手段是：
- HTML 原生属性
loading="lazy"：浏览器原生延迟加载，几乎零成本，但触发时机和距离阈值由浏览器内部决定，开发者不可控。 - Intersection Observer（IO）：JS 手动监听元素进入视口附近时再加载真实图片，可控性强，可以自定义阈值和提前量。
对瀑布流来说，纯loading="lazy"有一个坑：当你用 JS 动态插入新卡片时，部分浏览器对动态插入图片的懒加载支持并没有那么理想，或者会在布局计算之后才加载，导致高度突变。IO 方案则可以精确地控制加载触发时机。
如果追求工程化稳妥，采用"原生 lazy 保底 + IO 预加载"的组合：页面初始化时就给所有图片带上loading="lazy"，同时用 IO 监听可视区附近的图片，一旦进入提前量范围，立刻把真实的src赋上并取消懒加载标记。这样既照顾了不支持 IO 的环境，也保证了滚动体验。
关于图片 URL 本身，如果 CDN 支持?width=之类的动态裁剪参数，尽量在渲染时就按列宽生成对应尺寸的图片 URL，避免加载一张大图再被 CSS 缩小。我之前遇到过一次线上问题，同样的图片在某些机型上加载特别慢，排查后发现是静态资源服务没有开启自适应裁剪，列表页拖了几 MB 的图。换成按需缩略图后首屏体积大幅下降。
5.2 骨架屏与占位：让布局跳变动画可控
瀑布流最大的体验杀手不是"慢"，而是"乱跳"。图片还没加载时高度为 0 或很小，加载完成后卡片猛然撑开，导致用户正在阅读的内容被挤跑。解决方案是给每张图片设置一个基于比例的占位容器。
常见做法：
.card-image { position: relative; padding-top: 66.67%; /* 假设 3:2 比例 */ overflow: hidden; } .card-image img { position: absolute; top: 0; left: 0; width: 100%; height: 100%; object-fit: cover; }这种方式在图片未加载时容器就已经有了高度（由 padding 撑开），图片加载完成后只是替换内容，不会引起布局跳变。
但这里有个问题：瀑布流的图片比例往往是多样化的，如果全都按同一个比例占位，仍然是"假占位"。更好的方案是通过接口数据返回时携带图片宽高比，然后用内联样式或者 CSS 变量动态设置：
<div class="card-image" style="aspect-ratio: 4 / 3;"> <img src="..." alt=""> </div>aspect-ratio属性在现代浏览器中支持很好了，padding-top方案作为回退。给每个卡片设置准确的占位比例，布局稳定性会明显改善。
我自己的习惯是，在数据层就为每条内容计算好aspect-ratio并作为一个字段存下来，渲染层直接读取这个字段绑样式。这样不仅让占位准确，也方便后续做曝光埋数和视觉稳定性的量化统计。
5.3 content-visibility 与渲染性能的取舍
现代浏览器提供的content-visibility: auto属性可以跳过视口外元素的渲染，对长列表性能提升显著。它和瀑布流结合时，思路很直接：给每个卡片设置该属性，让屏幕外面的卡片不再参与完整的渲染和布局计算。
.card { content-visibility: auto; contain-intrinsic-size: auto 300px; /* 预估卡片高度，提供占位 */ }contain-intrinsic-size用于给未渲染的内容一个预估尺寸，否则滚动条的长度会因为内容"没高度"而跳动。这个值不需要精确，够用就行，浏览器会在实际渲染后修正。
需要注意content-visibility和瀑布流 JS 测量之间可能存在冲突：如果你用offsetHeight测量卡片真实高度，而未渲染的卡片高度可能因为content-visibility: auto而返回占位值，导致计算错误。解决办法：在测量时先临时移除该属性，或改用getBoundingClientRect()并接受近似值。
这个属性不是所有浏览器都支持，但目前主流环境没什么大问题。作为一个渐进增强手段，它对滚动流畅度的提升很有效。实际操作时我会先用一段脚本做能力检测，然后给容器加content-visibility: auto，并对测量逻辑做一个防御判断。
6. 踩坑实录与工程化避坑指南
6.1 图片加载时序导致的布局抖动
这是瀑布流开发中遇到频率最高的问题。现象是：页面打开后，部分卡片的位置不断地上下跳动，尤其底部图片加载时。
原因分析：很多方案在数据渲染后立即测量卡片高度并计算位置，但图片尚未加载完毕，卡片高度是"未撑开"状态；图片加载完成后高度瞬间变大，又触发重排。
我总结的排查思路：
- 打印卡片在加载前后的
getBoundingClientRect().height，确认是不是图片撑开导致。 - 检查图片是否设置了固定宽高或占位比例，如果没设，就先设
aspect-ratio。 - 检查是否监听了图片的
load事件并触发了重排——如果每个图片加载都触发一次全量重排，那抖动自然无法避免。优化做法是requestAnimationFrame合并触发，或者只在最后一个图片加载完成后重排一次。 - 在 React 环境下，惰性测量的记忆化处理也容易出问题：组件重新渲染时，样式被清掉或覆盖，需要通过
useLayoutEffect来维护布局状态。
合理的采坑建议是：不要让激活重排的粒度太细。全量重排尽量合并到一个任务里执行，用requestAnimationFrame做一次批量操作，比每次图片加载都重排体验好得多。
6.2 动态接口数据过滤后布局错位
当用户在前端对瀑布流做筛选（比如只看视频、只看图文）时，单纯改变数据源并重新渲染往往会出现：
- 卡片突然挤在一起，列数没有重新计算。
- 每列的卡片数量不一致（比如左边 3 张、右边 8 张）。
- 容器高度没有更新，出现空白区。
问题核心是：布局算法依赖的容器宽度和列高是旧值，数据变更后没有重新执行初始化流程。
解决办法：把布局模块抽成独立的类或者纯函数，对外暴露reset()方法。数据变更时先reset()清空容器、重置列高数组，再注入新数据重新布局。不要复用旧布局实例的状态。
我在这里还踩过一个隐蔽的坑：筛选时有些卡片因为在"最短列"判定上用的是列高的累计高度，而没有考虑它是否已经被卸载。如果卸载了卡片但列高没减，新卡片会被堆到一个超高的列下面，视觉上就出现右列长很多的情况。正确的做法是维护一份"存活状态"的数据结构，卸载卡片时要同步更新对应列的高度。
6.3 容器宽度变化（响应式）时的重算时机
瀑布流经常用在窗口宽度变化或侧边栏折叠的场景下。很多实现只在resize事件里做重算，但问题是：
- 移动端地址栏收起/展开会触发
resize，但不一定等于容器宽度变化。 resize事件在 PC 上联动输入法或 DevTools 打开时会非常频繁地触发。- 侧边栏折叠往往只是容器宽度变化，但窗口尺寸没变。
解决办法是用ResizeObserver监听容器本身，而不是window。ResizeObserver在元素尺寸变化时触发回调，精度高、性能也好。
const ro = new ResizeObserver(entries => { for (const entry of entries) { if (entry.contentRect.width !== lastWidth) { layout(); lastWidth = entry.contentRect.width; } } }); ro.observe(container);注意ResizeObserver的回调初始时会立即触发一次，需要做一次初始布局判断。另外，如果容器宽度连续变化（比如拖拽侧边栏），ResizeObserver触发频率依然很高，内部最好再做一次防抖或 RAF 合并。
6.4 常见问题速查表
| 现象 | 可能原因 | 解决方向 |
|---|---|---|
| 卡片堆叠不换行 | 容器宽度未正确获取或列宽设置过小 | 检查容器clientWidth，调整minmax()与 JS 列数计算逻辑 |
| 底部出现大片空白 | 容器高度未更新，或虚拟化占位高度不准确 | 在布局末尾更新容器style.height，校准contain-intrinsic-size |
| 图片加载后卡片错位 | 占位比例不准，或测量时机太早 | 使用aspect-ratio占位，监听加载完成重排 |
| 滚动到深处卡顿 | 真实 DOM 太多，或content-visibility未启用 | 考虑虚拟滚动，给卡片加content-visibility: auto |
| 更新数据后布局错乱 | 列高状态未随数据重置 | 抽出reset()方法，维护统一状态 |
| 跨列卡片显示异常 | Grid masonry 与 JS 方案行为不一致 | 仅保留单一方案实现跨列，或者对降级方案做额外处理 |
| 懒加载导致曝光数重复 | 懒加载与布局抖动竞争触发了 IO 回调多次 | 统一由 IO 控制曝光埋点，并与懒加载解耦 |
6.5 工程封装：把瀑布流做成可复用模块
最后分享一个我常用的封装思路，把瀑布流拆成三个关注点：数据层、布局层、渲染层。
- 数据层：负责维护数据列表，提供增删改查；对每条数据预先计算好宽高比、预估高度等元数据。
- 布局层：负责计算每个卡片的位置信息，对外暴露
layout(dataList)方法，返回卡片坐标数组。布局层不碰 DOM，只做纯计算，方便单测和替换算法。 - 渲染层：负责把坐标数组渲染成实际 DOM，绑定图片加载事件、滚动事件、点击事件。
分离之后，替换实现方案就很轻松。比如从 JS 绝对定位切成 Grid 原生方案，只需要替换布局层和渲染层，数据层完全不动。而且布局层的核心算法可以直接写单元测试——这是很多代码库里被忽略的环节。
在框架里使用的时候，把布局层放在一个模块级单例中，渲染层在组件里引用：
// layout.js let state = { cols: 0, colHeights: [], gap: 16, colWidth: 0 }; function setOptions(options) { state = { ...state, ...options }; } function reset() { state.colHeights = new Array(state.cols).fill(0); } function append(card) { const targetCol = state.colHeights.indexOf(Math.min(...state.colHeights)); card.x = targetCol * (state.colWidth + state.gap); card.y = state.colHeights[targetCol]; state.colHeights[targetCol] += card.height + state.gap; return card; }渲染层拿到坐标后执行 DOM 更新。这种思路保持了算法的纯粹性和可测试性。
7. 从 CSS Grid 原生到兼容方案的迁移实践
7.1 渐进增强迁移路径
如果你手头有一套旧的绝对定位瀑布流，想逐步向 CSS Grid 原生迁移，我建议的路径是：
- 保持现有 JS 布局入口不变，只替换容器类名与基础 CSS。
- 利用
@supports为新容器添加grid-template-rows: masonry，并在 JS 端能力检测后跳过布局脚本。 - 在灰度环境中对比两种实现的效果差异，主要关注：首屏顺序、滚动稳定性、图片加载节奏。
- 确认无误后去掉旧的绝对定位逻辑，保留 CSS 回退样式。
这样做的好处是风险小、可回滚。即使迁移过程中出现问题，只需关掉@supports分支就能回到旧方案。
7.2 一套代码走天下还是两套各管各？
这里要做一个权衡：一套代码（只走 JS 方案）简单粗暴，所有环境行为一致，但放弃了原生方案带来的性能红利；两套代码（CSS 原生 + JS 回退）体验更好，但维护成本翻倍。
我的观点是，看你的用户环境和团队规模。
面向 C 端、用户环境分散、团队有前端基建能力的，走两套渐进增强，收益明显。内部后台、用户环境统一（比如公司统一发放的机器）、团队人力紧张的，一套 JS 方案就够了，省心。
在实际项目里，我还见过一种折中思路：先用 JS 方案跑全量，后续如果通过数据发现支持原生环境的占比很高，再逐步加原生分支。这种"先上线再优化"的节奏很多场景下是更现实的。
7.3 从设计层面降低瀑布流实现难度
最后聊一个很多人忽略的点：瀑布流的实现难度，其实和设计规范强相关。
如果设计上允许"每张卡片高度近似固定"，比如统一图片比例或者统一文本行数，那么实现瀑布流的成本会直线下降——甚至columns以上就能满足。很多大厂的瀑布流看起来整齐不乱，背后其实就强制了卡片高度规范。
如果产品真正需要"完全自由、纯粹错落"的瀑布流，那就别想着省事，直接上完整的布局算法，并做好性能预案。
从我的经验看，约 80% 的瀑布流场景，通过合理的图片比例控制和内容裁剪，可以大幅降低布局算法的复杂度。这是瀑布流方案选型之前，最值得先想清楚的一件事。
我个人在实际操作中体会最深的一条是：瀑布流的难点不在于排布算法，而在于数据加载、图片生命周期和布局时机三者的协同。你把这几个环节理顺了，无论用原生 CSS 还是 JS 补偿方案，做出来的效果都不会差；否则就算算法再华丽，用户看到的依然是闪烁、跳动和卡顿。
最后再分享一个小技巧：开发时可以在页面里加一个调试开关，用可视化方式实时看每列高度数组和卡片坐标值。我之前就是这么排查一个"列倾斜"问题的——数据明明没问题，布局却一直左高右低，后来发现是某张卡片在加载后被外部脚本注入了额外样式，改变了高度。如果能直接从面板里看到列高数组的差异，就不会花那么久定位了。
如果你准备在 2026 年动手做新项目的瀑布流，我的建议直接抄作业：默认采用 Grid 布局 +@supports渐近增强，图片全部用aspect-ratio占位，容器用ResizeObserver做重算，图片加载用loading="lazy"保底和 IO 补充，列表过长再考虑虚拟滚动和content-visibility。这套组合在功能、性能和可控性之间，是我目前能给出的最佳平衡。
