grid-template-rows: masonry 目前不可用，因它仅是 css grid level 3 草案，主流浏览器均不支持（chrome 仅实验性支持且限制多），实际会回退为 none，无法实现瀑布流；可靠方案是 column-count 搭配 break-inside: avoid 或 javascript 库。
grid-template-rows: masonry 为什么现在还不能用
它目前只是 CSS Grid Level 3 的工作草案，所有主流浏览器都不支持（截至 2024 年中）。你写 grid-template-rows: masonry，浏览器会直接忽略该声明，回退到默认的 grid-template-rows: none 行为，结果通常是单列堆叠或按显式行高平铺，完全不是瀑布流效果。
常见错误现象：display: grid + grid-template-rows: masonry 写完页面毫无反应，开发者误以为是语法写错，反复检查拼写——其实不是写错，是根本没实现。
- Chrome 仅在 flag（
chrome://flags/#enable-experimental-web-platform-features）开启后，对grid-template-rows: masonry有极有限支持，且仅限于grid-auto-flow: column场景，不稳定、不兼容 SSR 和部分伪类 - Firefox 和 Safari 完全未实现该值，MDN 明确标注为 “Not supported”
- 即使未来支持，它也只控制“行方向”的 Masonry 布局，列数仍需靠
grid-template-columns或grid-auto-columns配合，单独写这一行不会自动分列
真正能落地的瀑布流方案只有两个
一是 JavaScript 方案（如 masonry-layout、packery 或原生 IntersectionObserver + 位置计算），二是纯 CSS 的 column-count 模拟。前者灵活可控，后者轻量但限制多。
用 column-count 实现时，关键不是“看起来像”，而是处理好内容截断和交互问题：
- 必须设置
column-gap，否则多列间内容会粘连 - 子项需声明
break-inside: avoid，否则图片或卡片可能被硬生生劈成两半 - 无法精确控制某一项落在第几列，DOM 顺序决定渲染顺序，不支持按高度动态排序
-
:hover、position: sticky等在多列中行为异常，特别是当子项含相对定位元素时
如果坚持用 Grid，替代 grid-template-rows: masonry 的可行写法
Grid 本身没有原生瀑布流，但可通过 grid-auto-flow: column + 固定行高模拟“近似”效果，适用于高度差异不大、内容结构规整的场景（比如图标列表、小尺寸卡片）。
示例核心代码：
.container {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(240px, 1fr));
grid-auto-flow: column;
grid-auto-rows: 200px; /* 必须设固定高度，否则等高 */
}
注意点：
-
grid-auto-rows是关键，它强制每行高度一致，Grid 才能按列“填满”；一旦设为auto，就退回普通块级流，失去列式布局意义 - 这个方案本质是“列优先网格”，不是瀑布流——所有项按 DOM 顺序从上到下、从左到右填入列，不会根据高度重排
- 响应式脆弱：列宽变化时，高度不变会导致大量空白或溢出，需配合 JS 监听 resize 重设
grid-auto-rows
别在生产环境赌 masonry 草案的兼容性
草案阶段的最大风险不是“不支持”，而是“部分支持但行为不一致”。比如 Chrome 某次更新后突然要求父容器必须有明确高度，或子项 margin 被忽略，这类变动不会发公告，只会导致线上瀑布流错乱。
如果你的项目需要可靠、可维护、SEO 友好的瀑布流，现阶段唯一推荐路径是：column-count + break-inside: avoid 保底，再用 ResizeObserver + 简单高度计算做渐进增强（比如调整列数或插入占位符）。真要动态排序和拖拽，就得上 JS 库——别省那几十 KB，省出来的技术债后期更贵。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
