纯CSS Grid无法实现真正瀑布流，因其静态轨道强制列高同步，而瀑布流需各列独立异步增长；目前仅部分浏览器支持masonry且限制严格，可靠方案为column-count或grid+JS动态分发。
纯 CSS Grid 无法实现传统瀑布流，因为它的轨道（rows/columns）是静态划分的，所有列高度强制同步拉伸——而瀑布流本质要求各列独立堆叠、高度异步增长。这不是写法问题，是模型设计层面的不兼容。
grid-template-rows: masonry 为什么不能直接用
它确实是规范里最接近原生解的方案，但目前仅 Chrome 117+ / Edge 116+ / Safari 17.4+（需开启实验标志）/ Firefox Nightly 支持；主流稳定版 Firefox 和 Safari 完全不识别该声明，@supports (grid-template-rows: masonry) 在这些浏览器中会解析失败，导致静默回退为单列布局。更关键的是，它有硬性限制：
-
grid-template-columns必须显式定义（如repeat(3, 1fr)），auto-fill或auto-fit会直接禁用 Masonry 行为 - 禁止任何手动定位：不能出现
grid-row-start、grid-column、grid-area - 卡片必须是容器的直接子元素，嵌套
display: flex或display: grid子容器会干扰列高测量 - 图片未加载时塌陷会导致初始错位，必须用
aspect-ratio或padding-top占位
grid-auto-flow: column + 固定行高只是视觉错觉
很多人试过 grid-auto-flow: column 配合 grid-auto-rows: 200px，结果发现不是错落而是大片留白或内容重叠。这是因为：
- 它依赖所有卡片高度是
grid-auto-rows的整数倍，而真实场景中图片加载、字体回流、line-height 变化都会让 runtime 高度突变 - 浏览器不会根据当前列总高选择“最短列”插入新项——Grid 没有调度逻辑，JS 才有
- 某列图片加载撑开后，其他列不会自动重平衡，视觉上立刻“歪掉”
真正能落地的替代方案只有两种
一种是轻量级、兼容性极佳但功能受限的：column-count 布局；另一种是可控性强、适配复杂交互但需处理细节的：grid-auto-flow: column + JS 动态分发。
立即学习“前端免费学习笔记（深入）”；
-
column-count: 3+break-inside: avoid：基于文本流自然分栏，各列高度天然不等，Chrome 50+ / Firefox 13+ / Safari 10.1+ 全支持，但子项不能是grid-item或flex-item，也不支持 hover 动画精确定位 -
grid-auto-flow: column+ JS：Grid 控制列宽与间距（如grid-template-columns: repeat(auto-fill, minmax(280px, 1fr)))），JS 负责维护columns = [0, 0, 0]数组记录每列当前总高，每次插入前找最小值索引，再用item.getBoundingClientRect().height更新——注意不能用offsetHeight，它含边框/滚动条误差 - 响应式重排必须用
ResizeObserver监听容器宽度变化，而非window.resize；图片加载完成（img.onload）或懒加载触发后，也得重新跑分配逻辑，否则列高计算失准
最容易被忽略的不是怎么写第一版，而是图片异步加载、字体回流、用户缩放这三件事叠加后的表现——它们不报错，但会让瀑布流看起来“卡住”或“突然跳变”。
