纯 css grid（level 2）无法实现真正的瀑布流，因其静态轨道划分与各列独立堆叠的本质需求不兼容；grid-template-rows: masonry 属于 level 3，仅 chrome/edge 116+ 支持，firefox/safari 不识别，@supports 检测失效；grid-auto-flow: column 或 dense 均为视觉近似，依赖固定高度假设，易因图片加载、字体渲染等导致错位；可靠方案仅有 column-count + break-inside（兼容性好但列宽不可控）或 grid + js 动态分发（可控但需处理 resizeobserver、图片延迟等细节）。
纯 CSS Grid（Level 2）无法实现真正的瀑布流，因为它的行/列轨道划分是静态的、全局对齐的，而瀑布流本质要求各列独立堆叠、高度异步增长——这是设计模型层面的不兼容。
grid-template-rows: masonry 不是 Level 2 特性，而是 Level 3
很多人误以为 grid-template-rows: masonry 是 CSS Grid Level 2 的一部分，其实它属于 CSS Grid Layout Level 3 规范。截至 2026 年 5 月，该特性仅在 Chrome 116+ 和 Edge 116+ 中稳定启用；Firefox 尚未实现，Safari 完全不识别该语法，且 @supports (grid-template-rows: masonry) 在这些浏览器中直接解析失败，无法用于可靠检测。
这意味着：如果你在项目中写 grid-template-rows: masonry，旧版或非 Chromium 内核环境会静默忽略该声明，回退为默认 grid-auto-flow: row，结果变成单列纵向排列，完全不是瀑布流。
grid-auto-flow: column + 静态行高只是视觉近似
用 grid-auto-flow: column 搭配 grid-auto-rows: 10px 看似能“错开”元素，但它依赖两个危险假设：
- 所有子项高度必须是
grid-auto-rows的整数倍（否则grid-row-end计算失准） - 内容高度在布局时已知且固定（但图片加载、字体渲染、
line-height变化都会导致 runtime 高度突变）
一旦某张图加载完成、撑开容器，整列后续元素就会下移，而其他列并不同步响应——这破坏了“最短列优先填充”的瀑布流逻辑，造成留白或重叠。你看到的“错落”，其实是渲染抖动下的偶然效果，不是可控布局。
为什么 grid-template-columns + auto-fill 也不行
grid-template-columns: repeat(auto-fill, minmax(250px, 1fr)) 这类写法本质是等宽网格（grid），不是瀑布流（masonry）：
- 元素严格按 DOM 顺序填入，从左到右、从上到下，每行填满才换行
- 每列高度由该列最高项决定，其余项底部强制对齐——这正是瀑布流要避免的“等高拉伸”
-
grid-auto-flow: dense只能填补已有空隙，不能动态重排已渲染的元素位置
它适合做响应式卡片墙，但不适合 Pinterest 或小红书那种靠列高最小化实时分配的布局。用它做瀑布流，等于把“行优先”强行当“列优先”用，方向反了。
真正能落地的方案只有两个现实路径
一是用 column-count + break-inside: avoid：浏览器原生支持列高均衡分配，无需 JS，兼容到 iOS Safari 10.3+，唯一缺点是列宽不可控、gap 表现不稳定；
二是 Grid 容器 + JS 动态分发：用 grid-template-columns 控制列数和宽度，JS 维护列高数组，调用 getBoundingClientRect().height 获取真实高度，再通过 order 或 appendChild 重排节点——这个方案可控、可响应式、可降级，但必须处理 ResizeObserver 重排、图片加载延迟、字体 FOIT 等细节。
别指望 Level 2 能解决这个问题。它没提供列级独立布局能力，也没引入任何新关键字或函数来绕过轨道对齐约束。所谓“Grid 实现瀑布流”，要么是误读规范，要么是拿近似效果凑数。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
