原生 display: masonry 目前不可用于生产环境，仅 chrome 114+ 实验性支持且需手动开启 flag，firefox 和 safari 完全不支持；“真正混合高度瀑布流”必须依赖 columns 布局或 css grid + js 计算的替代方案。
原生 display: masonry 目前（2026年7月）**仍不可用于生产环境**——它仅在 Chrome 114+ 中作为实验性功能默认启用，且需手动开启 chrome://flags/#enable-css-masonry-layout，Firefox 和 Safari 完全不支持。所谓“真正混合高度瀑布流”，现阶段必须绕过原生 CSS Masonry，用更可靠方案落地。
为什么不能直接用 display: masonry
你看到的 MDN 文档或某些博客里写的 display: masonry 示例，基本都运行在开启 flag 的 Chrome 里，一换浏览器就空白或回退成普通块级流。它不接受 grid 或 flex 的 fallback，也不触发任何降级行为。实际项目中，只要用户用 Safari 打开，整个布局就塌陷。
- Chrome：需用户主动开启 flag，无法通过代码控制
- Firefox：无实现计划，官方明确标注“Not planned”
- Safari：未出现在 WebKit Roadmap 中
- 即使在支持 Chrome 中，
gap、justify-content等属性仍不稳定，break-inside与masonry共存时行为异常
columns 多列布局的真实表现与坑点
这是目前兼容性最好（IE11+）、零 JS、纯 CSS 的方案，但它的“瀑布流”是**列优先填充**，不是视觉上期望的“行优先错落”。例如 6 个 item 高度分别为 [100, 200, 150, 80, 300, 120]，column-count: 3 会按顺序填满第 1 列（item 1→item 2→item 3），再填第 2 列（item 4→item 5），最后 item 6 落在第 3 列顶部——导致右侧列明显“矮一截”，视觉断层。
- 必须加
break-inside: avoid，否则长文本或图片可能被硬切到不同列 -
column-gap是列间距离，但 item 内部 margin 会叠加，容易撑出意外空白 - 响应式改列数时，需用
@media重置column-count，且区间不能重叠或留空（如max-width: 767px和min-width: 768px必须无缝衔接） - 容器必须有明确宽度（百分比或固定值），
width: 100%在 flex 或 grid 子项中可能失效
CSS Grid + JS 计算跨行数的可控方案
这是目前最接近“真瀑布流”体验的折中解：用 grid-auto-rows 设定最小行高基准，再用 JS 读取每个 item 的 offsetHeight，除以基准值得到 grid-row-end: span X。它能实现左→右→下的自然阅读流，且支持动态加载。
- Grid 容器设
grid-template-columns: repeat(auto-fill, minmax(300px, 1fr))实现响应式列数 -
grid-auto-rows: 10px是关键——太小（如 1px）会导致 JS 计算 span 值过大，触发渲染卡顿；太大（如 100px）则跨行不准，出现白边 - JS 必须在 DOM 渲染后执行（如
requestAnimationFrame或ResizeObserver），否则offsetHeight读不到真实值 - 每次新增 item，需重新计算全部（或增量计算），避免旧 item 跨行数失效
- 注意：不要用
height: 100%或aspect-ratio直接控制 item 高度，它们会影响 JS 读取的offsetHeight
框架插件选型的关键判断点
React/Vue 生态里一堆 “Masonry” 插件（如 react-masonry-css、vue-masonry），它们本质都是封装了 JS 计算 + Grid/CSS columns 的逻辑。是否引入，取决于三个硬指标：
- 是否支持服务端渲染（SSR）？多数插件依赖
window对象，直出时会报错，需加typeof window !== 'undefined'判断 - 是否提供
updateLayout手动触发方法？动态增删 item 时，自动监听不如显式调用稳定 - 是否暴露
itemSelector或containerRef？方便与 IntersectionObserver 结合做懒加载 - 注意：所有插件在 Safari 中都会回退到单列或 columns 布局，别指望它“自动修复”原生 Masonry 缺失
真正混合高度瀑布流的核心矛盾不在写法，而在“排列逻辑”和“浏览器能力”的错位。现在能做的，是明确知道每种方案在什么设备、什么交互场景下会失效，并提前兜底——比如用 @supports (display: masonry) 包裹原生尝试，但立刻用 columns 作 fallback，而不是把希望押在尚未落地的 CSS 特性上。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
