纯 CSS Grid 无法真正实现 Pinterest 风格瀑布流，因 grid-template-rows: masonry 尚未被主流浏览器稳定支持；推荐用 column-count + break-inside: avoid 模拟视觉效果，或使用 JavaScript（如 masonry-layout、react-masonry-css）实现真瀑布流。
纯 CSS Grid 无法真正实现 Pinterest 风格的瀑布流（即各列高度不齐、卡片按列“填空”式堆叠），grid-template-rows: masonry 尚未被任何主流浏览器稳定支持（截至 2024 年底仅 Chrome Canary 实验性开启且需 flag）。必须用 JavaScript 补位，或退而求其次用 CSS + 折中策略模拟视觉近似效果。
为什么 grid-template-rows: masonry 现在还不能用
该属性是 CSS Grid Level 3 规范的一部分，目标就是解决瀑布流，但实现严重滞后：display: grid 配合 grid-template-rows: masonry 在 Safari 完全不识别；Firefox 无支持；Chrome 需手动启用 chrome://flags/#enable-experimental-web-platform-features，且禁用子网格（subgrid）时可能崩溃。生产环境直接写会降级为等高行布局，卡片被强行拉伸变形。
用 column-count + break-inside: avoid 快速模拟（适合静态内容）
这是目前最轻量、兼容性最好的“视觉瀑布流”方案，原理是让容器变成多列流式布局，卡片自然按列顺序填充，不跨列断行。
-
column-count设定列数（如column-count: 3），注意它不响应式——需配合媒体查询手动切列数 - 每个卡片必须加
break-inside: avoid（或page-break-inside: avoid用于打印），否则长卡片会在列内被截断 - 卡片宽度设为
100%，不要设固定width，否则可能撑破单列 - 列间距用
column-gap，不是gap；垂直间距需用margin-bottom控制卡片自身
article.card {
break-inside: avoid;
margin-bottom: 1rem;
}
.container {
column-count: 3;
column-gap: 1.5rem;
}
用 JavaScript 实现真瀑布流（推荐 MASONRY 库）
当卡片高度差异大、需精准列高平衡、或内容动态加载时，必须 JS 控制。不建议手写 Masonry 布局逻辑（涉及列高追踪、最小列插入、重排性能优化），直接用成熟库更稳。
立即学习“前端免费学习笔记（深入）”；
-
masonry-layout（原生 JS，无依赖）：通过element.style.position = 'absolute'手动定位，需父容器position: relative，且脱离文档流——意味着无法与下方元素自然流式衔接 -
vanilla-masonry：更轻量，支持 resize 重排和添加/移除项，但不处理图片懒加载完成后的重新计算 - 如果已用 React，优先选
react-masonry-css或masonic（Virtualized + Masonry 合体，适合大数据量） - 关键陷阱：
img标签未加载完成时高度为 0，JS 会按 0 高度计算位置——务必监听load事件或使用IntersectionObserver触发重排
Grid + grid-auto-flow: dense 的误区与有限适用场景
有人尝试用 Grid 的 grid-auto-flow: dense 配合不同 grid-row-end 模拟错落，但这只是“手动指定每张卡占几行”，不是自动瀑布流。它只适用于卡片数量少、高度可预知、且能提前写死 grid-row 的静态画廊页。
- 一旦卡片高度由内容（如文字行数、图片尺寸）动态决定，就无法预设
grid-row -
dense只影响空位填充顺序，不改变轨道大小——所有行高仍由最高卡片撑开，最终仍是等高栅格 - 若强行用
grid-row: span 2等制造错落，响应式切换列数时极易错位，维护成本高
真正可靠的瀑布流永远绕不开 JS 计算列高；CSS 方案本质是“列流模拟”，胜在简单和渐进增强。别被 masonry 这个词迷惑——浏览器还没准备好，你得自己托住它。
