如果你做过前端估计已经不止一次听到这句话CSS终于能做瀑布流了三行代码搞定告别JavaScript布局。这条消息直接戳中一个长期存在的前端痛点那就是瀑布流布局。以前想实现瀑布流第一反应基本都是JS自己写绝对定位计算坐标或者引一个开源库而现在CSS Grid Layout 规范的新草案里加入了Masonry布局把这件事简化到了一个非常夸张的程度。这篇文章我就来聊聊这个新特性到底是什么、三行代码具体怎么写、和传统JS方案相比有哪些差异以及如果想在产品里提前用上它有哪些需要提前知道的坑。适合所有被瀑布流折磨过的前端也适合想提前了解CSS新布局能力的同学。1. 为什么说 CSS 终于能做瀑布流了1.1 先拆一下传统 JS 瀑布流是怎么跑的在说CSS方案之前我觉得有必要把过去我们常用的JS瀑布流原理捋一遍没有这个背景你对masonry这套东西的理解会很浅。经典的手写瀑布流核心思想其实就一句话把整个容器设成position: relative然后每个卡片position: absolute手动算出每一张卡片的left和top让它们填充到当前最短的那一列下面去。代码大概是长这样的// 计算每一列当前的高度 const colHeights new Array(colCount).fill(0); items.forEach((item) { // 找到当前最矮的列 const minIndex colHeights.indexOf(Math.min(...colHeights)); // 把这个卡片放进去 item.style.left minIndex * (colWidth gap) px; item.style.top colHeights[minIndex] px; // 更新该列高度 colHeights[minIndex] item.offsetHeight gap; });看起来不算复杂但实际用起来远没有这么简单。你得考虑图片没加载完时offsetHeight不准确要等图片读完了再加一次窗口变化导致列数变化时要重新计算下拉加载新数据时要对新增项再跑一遍布局。这些逻辑叠加起来很快就变成一个充满边界case的排序游戏。后来社区里也出现了用columns属性做的伪瀑布流写法倒是很简。.gallery { columns: 4; column-gap: 16px; }这确实很省事但有个很致命的问题内容顺序是纵向排列的也就是第一列从上到下排满再排第二列。用户横向扫过去的视觉顺序和DOM顺序严重不一致在一些注重阅读顺序的场景下很难接受。而CSS masonry布局就是专门为这类需求设计的原生方案。1.2 masonry 到底是个什么原理masonry这个词本意是“砖石砌筑”放在布局里指的就是那种砖墙一样错落排列的样式中文社区一般叫瀑布流。这套机制并不是凭空发明的而是作为CSS Grid布局的扩展来实现的。你可以理解为它允许你在grid的某一个轴上不再使用固定高度的行轨道而是改用“masonry堆叠模式”让每一列各自的高度独立变化新的子项会被自动放进当前最矮的那一列。也就是说浏览器引擎内部帮你实现了前面那段JS代码的逻辑。有人可能会问这和grid-auto-flow: dense不是一回事吗确实很多人会把这两个概念混淆。dense用于解决网格里的空洞问题它仍然是严格的网格行列每个格子都有固定轨道尺寸只是允许后面的子项“回头填坑”而masonry的根本区别是没有统一的行轨道每一列的轨道高度由各自的内容决定卡片之间形成自然的错落不会出现整行被撑高的现象。这个差异决定了两种布局的气质完全不同一个仍然像矩阵一个才是真正的瀑布流。1.3 三行代码的具体写法先看代码核心就三行.gallery { display: grid; grid-template-columns: repeat(4, 1fr); grid-template-rows: masonry; }就这三行一个最基本的瀑布流就完成了。其中grid-template-columns负责定义列数和列宽grid-template-rows: masonry负责开启纵向的瀑布流模式。子元素按普通div写就行不需要任何额外定位。如果你还想要子项间距再加一行gap: 16px就行。这也是很多人传的“三行代码”的真相。另外要说清楚一点grid-template-rows: masonry是针对纵向瀑布流。如果你把masonry写到grid-template-columns上得到的就是一个横向的masonry布局所有卡片会从左往右填满最矮的行——一般用在横幅墙、书架这类场景日常用得比较少知道有这回事就可以。看到这里你会觉得这套方案实在太香了。但先别急后面要聊的坑也不少。2. 完整实操从 JS 版改造到 CSS 版2.1 一个典型瀑布流页面的真实改造过程我拿之前做过的一个图片流页面来举例。原来的方案就是文章开头那种JS绝对定位背景是动态接口返回的图片列表图片尺寸完全不固定高度从200px到600px都有。改造的第一步是把容器的position: relative去掉直接改成grid.gallery { display: grid; grid-template-columns: repeat(auto-fill, minmax(240px, 1fr)); grid-template-rows: masonry; gap: 16px; }这里列宽我没有写死而是用repeat(auto-fill, minmax(240px, 1fr))这样在不同屏幕宽度下会自动适配列数。效果就是屏幕宽的时候列多屏幕窄的时候列少不用再监听resize手动算列宽响应式直接白拿。原来的JS代码我基本全删了只留下一个渲染列表的逻辑往容器里塞DOMasync function loadMore() { const list await fetchList(); const fragment document.createDocumentFragment(); list.forEach((item) { const card document.createElement(div); card.className card; card.innerHTML img src${item.cover} alt${item.title} p${item.title}/p ; fragment.appendChild(card); }); gallery.appendChild(fragment); }页面跑起来以后新插入的卡片会由浏览器自动分配到一个最矮的列完全不需要再调用一个layout函数连ResizeObserver都省了。改造完之后对比一下JS代码量大幅缩减肉眼可见的维护成本下降。那个页面上线后布局相关的bug也变少了这类问题我再也没怎么碰过。2.2 浏览器怎么自动决定每个卡片放在哪一列这一节我想把masonry的核心调度逻辑讲透因为它决定了你排出来的瀑布流长什么样。默认情况下浏览器会维护一个“当前各列高度”的数组。每个新的子项进入布局时查找当前高度最小的那一列把卡片放到那一列的末尾。这和手动JS版本的逻辑几乎一样。听起来很合理但有一个隐藏细节masonry并不像很多想象中的那样“图像重排”它是按照DOM顺序依次往下塞。所以只要你的数据源顺序是1、2、3、4那么最终视觉上虽然交错但整体顺序不会乱。这一点对于新闻资讯流、用户动态流很重要不会出现为了填充空洞而打乱内容顺序的问题。如果你希望优先把卡片放在最前面尚未使用的列而不是放在最矮的列可以使用masonry-auto-flow: next来控制.gallery { display: grid; grid-template-columns: repeat(4, 1fr); grid-template-rows: masonry; masonry-auto-flow: next; }这个属性比较冷门但做特殊布局时很有用。比如你有一批固定顺序的banner希望它们从左到右严格依次排列同时又想保留瀑布流底部错落效果时next会更好用。2.3 几个让瀑布流更好看的细节参数把基础布局跑通之后想让页面更精致可以调整几个容易被忽略的参数。第一gap千万别忘。瀑布流讲究疏密有致如果卡片之间没有间距视觉上会非常拥挤。一般建议和外层容器的其他间距保持一致比如16px或24px。注意这里不要用marginmargin在做响应式缩进、背景色处理时会产生很多奇怪的叠加问题统一用gap最干净。第二卡片内部的图片要设置成自适应宽度。最常用的写法是.card img { width: 100%; height: auto; display: block; }不写display: block的话图片底部会出现大约4px空隙这在瀑布流里做圆角卡片时特别明显会平白多出一截。第三如果你想控制masonry卡片的最小高度或者统一比例可以用aspect-ratio。但注意不要过分使用瀑布流的精髓是高度自然。只要这三件事做好出来的效果已经能接近设计稿了。3. 和 JavaScript 方案对比到底谁赢3.1 一张表看清两种方案的差距很多人在选型时会纠结CSS masonry这么好JavaScript是不是该彻底退场了其实没那么简单先看一张对比表对比维度CSS masonryJS 绝对定位方案实现成本三行CSS计算列宽、高度数组、窗口监听、图片监听内容顺序天然保留DOM顺序视实现质量而定多数也保留动态高度浏览器自动计算图片加载失败、懒加载时容易算错响应式列数直接用auto-fill需要JS监听resize并重跑布局性能原生布局引擎处理每次layout都在JS里操作大量offsetHeight浏览器兼容实验特性需flag几乎所有浏览器都支持额外依赖无通常依赖库或自研工具函数从这个表能看出来CSS方案几乎全面领先唯一短板就是兼容性。3.2 什么场景该用 CSS 而不是 JS先说不该用JS的场景。如果你做的是一个展示型图片流页面比如设计灵感墙、数据可视化大屏里的卡片列表、个人博客的文章精选这类场景最大的诉求是快速实现、视觉效果好、后续维护少。只要你的用户群体相对可控或者你能接受“不支持时退回普通grid”直接用CSS masonry非常合适。我个人的经验是这类页面用CSS masonry还有一个隐藏优势你不再需要维护一整套“页面数据变化后同步更新布局坐标”的逻辑新增删改都只是操作DOM浏览器会自动处理位置。团队里哪怕是个刚接手的新人也能很快上手。尤其当你的卡片里包含复杂内容、嵌套组件、自定义字体时JS方案经常因为某个卡片高度在渲染瞬间没稳定而抖一下CSS方案不会出现这个问题。3.3 不支持的浏览器怎么降级正因为兼容性还没完全普及降级策略很关键。我自己在实际项目里用的思路是渐进增强先保证所有浏览器都能看到完整内容支持masonry的浏览器再体验瀑布流效果。核心工具是supports.gallery { display: grid; grid-template-columns: repeat(auto-fill, minmax(240px, 1fr)); gap: 16px; } supports (grid-template-rows: masonry) { .gallery { grid-template-rows: masonry; } }不支持的浏览器会走普通的网格布局每行高度由该行最高卡片决定。这虽然不是瀑布流但内容完整、视觉整齐用户基本察觉不到异样。如果产品经理死活要求所有浏览器都必须是瀑布流效果那就只能回到JS方案但是可以把JS库作为降级策略包在最外层等CSS masonry普及之后再拆掉。这种思路我实际落地过几次过渡过程非常平滑。4. 踩坑与排查masonry 上线前必须知道的事4.1 图片加载导致的高度抖动很多人第一次用masonry会忽略一个现象图片还没加载完成时卡片高度可能是0或者只有文字高度。等图片慢慢加载进来卡片高度突然变大浏览器就会重新安排列的位置视觉上出现上上下下的跳动。这在JS方案里同样存在但CSS masonry已经算表现好的了因为它不会给你显示出大片空白列而是尽量把新卡片塞到矮的列上。但跳动本身还是会影响体验。我的建议是给图片加上宽高占位现在浏览器的做法是.card img { width: 100%; height: auto; aspect-ratio: attr(width) / attr(height); }配合在HTML里写清楚width和height属性浏览器能提前算出图片的比例占好位置整个瀑布流会稳定很多。如果图片宽高比差异极大还可以用min-height给所有卡片一个下限减少极端抖动。4.2 响应式断点的切换CSS masonry对响应式的处理是自动的但有个细节容易踩坑当你用auto-fill和minmax时列数会随着屏幕宽度自动增减但masonry的队列状态是跟着grid容器走的。在窗口切换断点时我之前观察到有些版本的浏览器需要触发重排才会让列高数组正确重置。实际解决办法很简单在容器上做一个文档渲染标记。比如给容器添加或移除一个类名强制浏览器重新评估布局window.addEventListener(resize, () { gallery.classList.toggle(resizing); });这个用法比较tricky如果遇到列切换后布局错乱可以试试。如果没有问题不要主动加多一事不如少一事。4.3 键盘顺序和读屏体验瀑布流天然是二维视觉排列但它背后的DOM顺序仍然是线性一维的。键盘用户在Tab切换时焦点是从上到下按DOM顺序移动而不是视觉上的从左到右再从上到下。对于内容冲淡的图片墙来说一般还好但如果是表单卡片、可交互卡片组成的信息流这一点需要特别注意。我通常会建议卡片本身如果包含链接把所有交互元素都做成可聚焦的并且不要让一个卡片里出现好几个并列Tab点。读屏用户访问时要保证每个卡片有一个能概括内容的名字比如给整个卡片加aria-label。这些细节看起来和“瀑布流”关系不大但上线后被QA测试和用户反馈逼着修的次数比布局本身多得多。4.4 用 content-visibility 优化长列表性能瀑布流页面普遍很长图片很多滚动起来如果每一帧都要渲染几十个离屏卡片性能总会下降。CSS masonry本身没有解决这个问题要优化还得靠自己。我推荐给每个卡片加上这行.card { content-visibility: auto; contain-intrinsic-size: 300px; }content-visibility: auto可以让浏览器跳过屏幕外卡片的渲染工作滚动进入视口时才真正渲染内容。contain-intrinsic-size是配合它使用告诉浏览器离屏时这个卡片大概占多大避免出现滚动条疯狂跳动。实测下来对长列表瀑布流的滚动流畅度提升非常明显尤其是移动端。这个优化对JS方案同样适用但和CSS masonry结合时因为不需要JS计算坐标整个页面在滚动过程中几乎纯靠浏览器原生渲染体验非常顺。4.5 常见问题速查表我把平时被问到最多的问题整理成了一张表大家可以直接对照现象原因解决方式没有瀑布流效果卡片按网格排列浏览器没开启masonry或实验flag关闭开启实验特性或者用supports检查卡片顺序混乱用masonry-auto-flow: next仍不满足需求重新梳理DOM顺序按优先级排好图片底部有白边图片inline导致display: block首屏布局跳动图片没占位加aspect-ratio设min-height窗口缩放后布局卡住response断点触发问题给容器切换类名强制重排滚动时明显掉帧离屏内容仍在渲染加content-visibility: auto无法使用grid-auto-rows同行效果masonry模式不支持某些网格属性改用内容撑开高度或用JS fallback5. 从做项目角度看什么时候用 CSS 别用 JS5.1 选型时的一张决策清单如果你正在评估下一个项目的瀑布流方案我这里有一套自己用的决策流程你可以直接抄。第一步先问自己这个页面是不是纯展示性质如果答案是肯定的直接选CSS masonry同时把supports的降级写好。第二步问卡片内容交互复杂吗比如有评论、点赞、收藏、动态表单这种高度动态的交互内容卡片高度可能因为用户操作随时变化。CSS masonry面对频繁内容变化时浏览器重排压力会增大尤其是同时展示几十上百个活跃交互卡片时可能会不如JS定制方案那么可控。第三步问页面数据量有多大如果超过500甚至上千条而且要无限滚动我会倾向于用虚拟滚动方案。这时候无论是CSS还是普通JS都不是最优解真正的王者是虚拟列表只渲染可视窗口内那一小部分DOM。masonry这种全量渲染模式并不适合海量数据。这三步问完大部分场景的答案已经很明确了。5.2 实验状态 API 上生产的注意事项现在这个特性还处于实验阶段真要上生产一定要把风险管理好。首先代码里所有masonry相关写法都要集中封装不要散落在各个组件里。比如封装成一个.masonry-container类将来如果属性名改了、或者有了新的标准写法你只需要改一处。其次利用supports做能力检测是底线生产代码里一定要有。不要让不支持的用户看到一个毫无样式的大网格至少给他们一个还算整齐的内容排列。最后关注规范的变动。这个特性目前还在草案推进阶段属性名、行为细节都可能调整。如果哪天标准定稿了再回来检查一次自己的用法是否需要迁移。这也是我为什么建议把masonry相关CSS独立写在文件最底部和业务样式分开方便未来替换。回头看一下CSS masonry最让我舒服的地方并不是省了那几行JS而是它把布局这件事重新还给了CSS——一个本来就该负责布局的语言。前端这些年堆积了太多由浏览器能力不足而诞生的JS库每少一个维护起来就轻松一分。如果你现在正好要写一个瀑布流页面大胆试一次原生masonry那个感觉真的不一样。
如果你做过前端估计已经不止一次听到这句话CSS终于能做瀑布流了三行代码搞定告别JavaScript布局。这条消息直接戳中一个长期存在的前端痛点那就是瀑布流布局。以前想实现瀑布流第一反应基本都是JS自己写绝对定位计算坐标或者引一个开源库而现在CSS Grid Layout 规范的新草案里加入了Masonry布局把这件事简化到了一个非常夸张的程度。这篇文章我就来聊聊这个新特性到底是什么、三行代码具体怎么写、和传统JS方案相比有哪些差异以及如果想在产品里提前用上它有哪些需要提前知道的坑。适合所有被瀑布流折磨过的前端也适合想提前了解CSS新布局能力的同学。1. 为什么说 CSS 终于能做瀑布流了1.1 先拆一下传统 JS 瀑布流是怎么跑的在说CSS方案之前我觉得有必要把过去我们常用的JS瀑布流原理捋一遍没有这个背景你对masonry这套东西的理解会很浅。经典的手写瀑布流核心思想其实就一句话把整个容器设成position: relative然后每个卡片position: absolute手动算出每一张卡片的left和top让它们填充到当前最短的那一列下面去。代码大概是长这样的// 计算每一列当前的高度 const colHeights new Array(colCount).fill(0); items.forEach((item) { // 找到当前最矮的列 const minIndex colHeights.indexOf(Math.min(...colHeights)); // 把这个卡片放进去 item.style.left minIndex * (colWidth gap) px; item.style.top colHeights[minIndex] px; // 更新该列高度 colHeights[minIndex] item.offsetHeight gap; });看起来不算复杂但实际用起来远没有这么简单。你得考虑图片没加载完时offsetHeight不准确要等图片读完了再加一次窗口变化导致列数变化时要重新计算下拉加载新数据时要对新增项再跑一遍布局。这些逻辑叠加起来很快就变成一个充满边界case的排序游戏。后来社区里也出现了用columns属性做的伪瀑布流写法倒是很简。.gallery { columns: 4; column-gap: 16px; }这确实很省事但有个很致命的问题内容顺序是纵向排列的也就是第一列从上到下排满再排第二列。用户横向扫过去的视觉顺序和DOM顺序严重不一致在一些注重阅读顺序的场景下很难接受。而CSS masonry布局就是专门为这类需求设计的原生方案。1.2 masonry 到底是个什么原理masonry这个词本意是“砖石砌筑”放在布局里指的就是那种砖墙一样错落排列的样式中文社区一般叫瀑布流。这套机制并不是凭空发明的而是作为CSS Grid布局的扩展来实现的。你可以理解为它允许你在grid的某一个轴上不再使用固定高度的行轨道而是改用“masonry堆叠模式”让每一列各自的高度独立变化新的子项会被自动放进当前最矮的那一列。也就是说浏览器引擎内部帮你实现了前面那段JS代码的逻辑。有人可能会问这和grid-auto-flow: dense不是一回事吗确实很多人会把这两个概念混淆。dense用于解决网格里的空洞问题它仍然是严格的网格行列每个格子都有固定轨道尺寸只是允许后面的子项“回头填坑”而masonry的根本区别是没有统一的行轨道每一列的轨道高度由各自的内容决定卡片之间形成自然的错落不会出现整行被撑高的现象。这个差异决定了两种布局的气质完全不同一个仍然像矩阵一个才是真正的瀑布流。1.3 三行代码的具体写法先看代码核心就三行.gallery { display: grid; grid-template-columns: repeat(4, 1fr); grid-template-rows: masonry; }就这三行一个最基本的瀑布流就完成了。其中grid-template-columns负责定义列数和列宽grid-template-rows: masonry负责开启纵向的瀑布流模式。子元素按普通div写就行不需要任何额外定位。如果你还想要子项间距再加一行gap: 16px就行。这也是很多人传的“三行代码”的真相。另外要说清楚一点grid-template-rows: masonry是针对纵向瀑布流。如果你把masonry写到grid-template-columns上得到的就是一个横向的masonry布局所有卡片会从左往右填满最矮的行——一般用在横幅墙、书架这类场景日常用得比较少知道有这回事就可以。看到这里你会觉得这套方案实在太香了。但先别急后面要聊的坑也不少。2. 完整实操从 JS 版改造到 CSS 版2.1 一个典型瀑布流页面的真实改造过程我拿之前做过的一个图片流页面来举例。原来的方案就是文章开头那种JS绝对定位背景是动态接口返回的图片列表图片尺寸完全不固定高度从200px到600px都有。改造的第一步是把容器的position: relative去掉直接改成grid.gallery { display: grid; grid-template-columns: repeat(auto-fill, minmax(240px, 1fr)); grid-template-rows: masonry; gap: 16px; }这里列宽我没有写死而是用repeat(auto-fill, minmax(240px, 1fr))这样在不同屏幕宽度下会自动适配列数。效果就是屏幕宽的时候列多屏幕窄的时候列少不用再监听resize手动算列宽响应式直接白拿。原来的JS代码我基本全删了只留下一个渲染列表的逻辑往容器里塞DOMasync function loadMore() { const list await fetchList(); const fragment document.createDocumentFragment(); list.forEach((item) { const card document.createElement(div); card.className card; card.innerHTML img src${item.cover} alt${item.title} p${item.title}/p ; fragment.appendChild(card); }); gallery.appendChild(fragment); }页面跑起来以后新插入的卡片会由浏览器自动分配到一个最矮的列完全不需要再调用一个layout函数连ResizeObserver都省了。改造完之后对比一下JS代码量大幅缩减肉眼可见的维护成本下降。那个页面上线后布局相关的bug也变少了这类问题我再也没怎么碰过。2.2 浏览器怎么自动决定每个卡片放在哪一列这一节我想把masonry的核心调度逻辑讲透因为它决定了你排出来的瀑布流长什么样。默认情况下浏览器会维护一个“当前各列高度”的数组。每个新的子项进入布局时查找当前高度最小的那一列把卡片放到那一列的末尾。这和手动JS版本的逻辑几乎一样。听起来很合理但有一个隐藏细节masonry并不像很多想象中的那样“图像重排”它是按照DOM顺序依次往下塞。所以只要你的数据源顺序是1、2、3、4那么最终视觉上虽然交错但整体顺序不会乱。这一点对于新闻资讯流、用户动态流很重要不会出现为了填充空洞而打乱内容顺序的问题。如果你希望优先把卡片放在最前面尚未使用的列而不是放在最矮的列可以使用masonry-auto-flow: next来控制.gallery { display: grid; grid-template-columns: repeat(4, 1fr); grid-template-rows: masonry; masonry-auto-flow: next; }这个属性比较冷门但做特殊布局时很有用。比如你有一批固定顺序的banner希望它们从左到右严格依次排列同时又想保留瀑布流底部错落效果时next会更好用。2.3 几个让瀑布流更好看的细节参数把基础布局跑通之后想让页面更精致可以调整几个容易被忽略的参数。第一gap千万别忘。瀑布流讲究疏密有致如果卡片之间没有间距视觉上会非常拥挤。一般建议和外层容器的其他间距保持一致比如16px或24px。注意这里不要用marginmargin在做响应式缩进、背景色处理时会产生很多奇怪的叠加问题统一用gap最干净。第二卡片内部的图片要设置成自适应宽度。最常用的写法是.card img { width: 100%; height: auto; display: block; }不写display: block的话图片底部会出现大约4px空隙这在瀑布流里做圆角卡片时特别明显会平白多出一截。第三如果你想控制masonry卡片的最小高度或者统一比例可以用aspect-ratio。但注意不要过分使用瀑布流的精髓是高度自然。只要这三件事做好出来的效果已经能接近设计稿了。3. 和 JavaScript 方案对比到底谁赢3.1 一张表看清两种方案的差距很多人在选型时会纠结CSS masonry这么好JavaScript是不是该彻底退场了其实没那么简单先看一张对比表对比维度CSS masonryJS 绝对定位方案实现成本三行CSS计算列宽、高度数组、窗口监听、图片监听内容顺序天然保留DOM顺序视实现质量而定多数也保留动态高度浏览器自动计算图片加载失败、懒加载时容易算错响应式列数直接用auto-fill需要JS监听resize并重跑布局性能原生布局引擎处理每次layout都在JS里操作大量offsetHeight浏览器兼容实验特性需flag几乎所有浏览器都支持额外依赖无通常依赖库或自研工具函数从这个表能看出来CSS方案几乎全面领先唯一短板就是兼容性。3.2 什么场景该用 CSS 而不是 JS先说不该用JS的场景。如果你做的是一个展示型图片流页面比如设计灵感墙、数据可视化大屏里的卡片列表、个人博客的文章精选这类场景最大的诉求是快速实现、视觉效果好、后续维护少。只要你的用户群体相对可控或者你能接受“不支持时退回普通grid”直接用CSS masonry非常合适。我个人的经验是这类页面用CSS masonry还有一个隐藏优势你不再需要维护一整套“页面数据变化后同步更新布局坐标”的逻辑新增删改都只是操作DOM浏览器会自动处理位置。团队里哪怕是个刚接手的新人也能很快上手。尤其当你的卡片里包含复杂内容、嵌套组件、自定义字体时JS方案经常因为某个卡片高度在渲染瞬间没稳定而抖一下CSS方案不会出现这个问题。3.3 不支持的浏览器怎么降级正因为兼容性还没完全普及降级策略很关键。我自己在实际项目里用的思路是渐进增强先保证所有浏览器都能看到完整内容支持masonry的浏览器再体验瀑布流效果。核心工具是supports.gallery { display: grid; grid-template-columns: repeat(auto-fill, minmax(240px, 1fr)); gap: 16px; } supports (grid-template-rows: masonry) { .gallery { grid-template-rows: masonry; } }不支持的浏览器会走普通的网格布局每行高度由该行最高卡片决定。这虽然不是瀑布流但内容完整、视觉整齐用户基本察觉不到异样。如果产品经理死活要求所有浏览器都必须是瀑布流效果那就只能回到JS方案但是可以把JS库作为降级策略包在最外层等CSS masonry普及之后再拆掉。这种思路我实际落地过几次过渡过程非常平滑。4. 踩坑与排查masonry 上线前必须知道的事4.1 图片加载导致的高度抖动很多人第一次用masonry会忽略一个现象图片还没加载完成时卡片高度可能是0或者只有文字高度。等图片慢慢加载进来卡片高度突然变大浏览器就会重新安排列的位置视觉上出现上上下下的跳动。这在JS方案里同样存在但CSS masonry已经算表现好的了因为它不会给你显示出大片空白列而是尽量把新卡片塞到矮的列上。但跳动本身还是会影响体验。我的建议是给图片加上宽高占位现在浏览器的做法是.card img { width: 100%; height: auto; aspect-ratio: attr(width) / attr(height); }配合在HTML里写清楚width和height属性浏览器能提前算出图片的比例占好位置整个瀑布流会稳定很多。如果图片宽高比差异极大还可以用min-height给所有卡片一个下限减少极端抖动。4.2 响应式断点的切换CSS masonry对响应式的处理是自动的但有个细节容易踩坑当你用auto-fill和minmax时列数会随着屏幕宽度自动增减但masonry的队列状态是跟着grid容器走的。在窗口切换断点时我之前观察到有些版本的浏览器需要触发重排才会让列高数组正确重置。实际解决办法很简单在容器上做一个文档渲染标记。比如给容器添加或移除一个类名强制浏览器重新评估布局window.addEventListener(resize, () { gallery.classList.toggle(resizing); });这个用法比较tricky如果遇到列切换后布局错乱可以试试。如果没有问题不要主动加多一事不如少一事。4.3 键盘顺序和读屏体验瀑布流天然是二维视觉排列但它背后的DOM顺序仍然是线性一维的。键盘用户在Tab切换时焦点是从上到下按DOM顺序移动而不是视觉上的从左到右再从上到下。对于内容冲淡的图片墙来说一般还好但如果是表单卡片、可交互卡片组成的信息流这一点需要特别注意。我通常会建议卡片本身如果包含链接把所有交互元素都做成可聚焦的并且不要让一个卡片里出现好几个并列Tab点。读屏用户访问时要保证每个卡片有一个能概括内容的名字比如给整个卡片加aria-label。这些细节看起来和“瀑布流”关系不大但上线后被QA测试和用户反馈逼着修的次数比布局本身多得多。4.4 用 content-visibility 优化长列表性能瀑布流页面普遍很长图片很多滚动起来如果每一帧都要渲染几十个离屏卡片性能总会下降。CSS masonry本身没有解决这个问题要优化还得靠自己。我推荐给每个卡片加上这行.card { content-visibility: auto; contain-intrinsic-size: 300px; }content-visibility: auto可以让浏览器跳过屏幕外卡片的渲染工作滚动进入视口时才真正渲染内容。contain-intrinsic-size是配合它使用告诉浏览器离屏时这个卡片大概占多大避免出现滚动条疯狂跳动。实测下来对长列表瀑布流的滚动流畅度提升非常明显尤其是移动端。这个优化对JS方案同样适用但和CSS masonry结合时因为不需要JS计算坐标整个页面在滚动过程中几乎纯靠浏览器原生渲染体验非常顺。4.5 常见问题速查表我把平时被问到最多的问题整理成了一张表大家可以直接对照现象原因解决方式没有瀑布流效果卡片按网格排列浏览器没开启masonry或实验flag关闭开启实验特性或者用supports检查卡片顺序混乱用masonry-auto-flow: next仍不满足需求重新梳理DOM顺序按优先级排好图片底部有白边图片inline导致display: block首屏布局跳动图片没占位加aspect-ratio设min-height窗口缩放后布局卡住response断点触发问题给容器切换类名强制重排滚动时明显掉帧离屏内容仍在渲染加content-visibility: auto无法使用grid-auto-rows同行效果masonry模式不支持某些网格属性改用内容撑开高度或用JS fallback5. 从做项目角度看什么时候用 CSS 别用 JS5.1 选型时的一张决策清单如果你正在评估下一个项目的瀑布流方案我这里有一套自己用的决策流程你可以直接抄。第一步先问自己这个页面是不是纯展示性质如果答案是肯定的直接选CSS masonry同时把supports的降级写好。第二步问卡片内容交互复杂吗比如有评论、点赞、收藏、动态表单这种高度动态的交互内容卡片高度可能因为用户操作随时变化。CSS masonry面对频繁内容变化时浏览器重排压力会增大尤其是同时展示几十上百个活跃交互卡片时可能会不如JS定制方案那么可控。第三步问页面数据量有多大如果超过500甚至上千条而且要无限滚动我会倾向于用虚拟滚动方案。这时候无论是CSS还是普通JS都不是最优解真正的王者是虚拟列表只渲染可视窗口内那一小部分DOM。masonry这种全量渲染模式并不适合海量数据。这三步问完大部分场景的答案已经很明确了。5.2 实验状态 API 上生产的注意事项现在这个特性还处于实验阶段真要上生产一定要把风险管理好。首先代码里所有masonry相关写法都要集中封装不要散落在各个组件里。比如封装成一个.masonry-container类将来如果属性名改了、或者有了新的标准写法你只需要改一处。其次利用supports做能力检测是底线生产代码里一定要有。不要让不支持的用户看到一个毫无样式的大网格至少给他们一个还算整齐的内容排列。最后关注规范的变动。这个特性目前还在草案推进阶段属性名、行为细节都可能调整。如果哪天标准定稿了再回来检查一次自己的用法是否需要迁移。这也是我为什么建议把masonry相关CSS独立写在文件最底部和业务样式分开方便未来替换。回头看一下CSS masonry最让我舒服的地方并不是省了那几行JS而是它把布局这件事重新还给了CSS——一个本来就该负责布局的语言。前端这些年堆积了太多由浏览器能力不足而诞生的JS库每少一个维护起来就轻松一分。如果你现在正好要写一个瀑布流页面大胆试一次原生masonry那个感觉真的不一样。
