纯CSS Grid无法实现真正瀑布流，因grid-auto-rows+span依赖预知高度、不自动避让空白、列间不联动，仅适用于内容高度稳定且无动态变化的SSR场景。
纯 CSS Grid 无法实现真正意义上的瀑布流，grid-auto-rows 配合 grid-row-end: span 只能模拟出近似效果，且高度依赖内容可预测性——它不是 Masonry，也不自动避让空白。
为什么 grid-auto-rows + span 不是真瀑布流
这个方案本质是“固定行高切片 + 手动跨行”，所有项目都按预设的 grid-auto-rows（比如 10px）被切成小段，再用 grid-row-end: span N 占据 N 行。问题在于：
- 内容高度必须提前知道或可稳定估算，否则
span值会错（文字换行、图片懒加载、字体加载延迟都会导致实际高度变化） - 浏览器不会重排已分配的项目去填补上方空洞，
grid-auto-flow: dense对跨行项基本无效 - 列之间完全不联动，某列底部留白时，其他列无法向下延伸填充
什么时候可以勉强用这个组合
仅适用于以下场景：
- 卡片内容高度差异小、结构高度一致（如统一标题+两行摘要+固定图标）
- 服务端渲染（SSR）且首屏内容高度可精确控制（例如 CMS 预计算了每张图的宽高比）
- 不需要动态插入新项，也不响应 resize 重排（否则需 JS 全量重算
span） - 目标浏览器支持
grid-auto-flow: dense（IE 完全不支持，旧版 Safari 行为异常）
示例中常见的 grid-auto-rows: 10px 和 .item.tall { grid-row-end: span 12; }，实际是把布局逻辑从 CSS 推给了开发者——你得自己决定“多高算 tall”。
立即学习“前端免费学习笔记（深入）”；
span 值怎么算才不容易翻车
不能靠目测或固定写死。真实项目里必须结合 JS 动态设置：
- 用
getBoundingClientRect().height获取渲染后真实高度（注意：需等图片加载完成、字体就绪） - 除以
grid-auto-rows值（如 10px），再向上取整：Math.ceil(realHeight / 10) - 避免直接设
span 1—— 这会导致项目被压进单行，文字溢出或图片裁剪；最小建议span 3起步 - 务必加防抖：窗口 resize 或图片 load 后延迟 50ms 再计算，防止连续触发 layout
别忘了监听 ResizeObserver，而不是 window.resize —— 列数变化时容器宽度可能不变，但 grid-template-columns 已重算。
兼容性和 fallback 必须手动写死
@supports (grid-template-rows: masonry) 在 Safari/Firefox 中永远返回 false，检测无意义。正确做法是：
- 用
@supports not (grid-template-rows: masonry)匹配不支持环境 - 降级到
column-count多列布局（注意加break-inside: avoid，否则图片会被截断） - 不要指望
grid-auto-flow: column—— 它在多数浏览器中会退化成单列，且无法控制列宽下限 - 移动端小屏强制单列：
@media (max-width: 480px) { column-count: 1; }，否则多列在窄屏上挤压变形
最麻烦的是：一旦用了 JS 动态 span，你就绕不开首屏闪动——DOM 渲染后高度为 0，JS 计算前所有卡片挤在第一行。这个视觉缺陷无法用 CSS 规避，只能靠骨架屏或 SSR 预置高度硬扛。
