瀑布流不能用 grid-row 跨行，因多列流布局不支持 row-span；真实瀑布流需 JS 测各列高度、插入最短列，并通过设置 height 模拟跨行，同时必须处理图片加载导致的高度塌陷。
瀑布流布局为什么不能直接用 CSS grid 的 grid-row 跨行？
因为标准 CSS 瀑布流（column-count + column-gap）本质是多列文本流，元素按文档流顺序填入各列，不支持对单个元素指定跨几列或“跨几行”——grid-row: span 3 在 grid 布局中有效，但在多列流布局里完全无效。你试图给子项加 row-span 属性，但这个属性根本不存在于 CSS 规范中，浏览器会直接忽略。
JS 计算“视觉行高”并动态设置 height 是最可控的方案
真实瀑布流（如 Pinterest）依赖 JS 测量每列当前高度，把新元素插入最短列。所谓“跨行”，其实是让某个元素的 height 恰好等于 N 个基础行高的总和，从而在视觉上占据多行位置。关键不是伪造 row-span，而是控制高度与列对齐。
- 先获取所有列容器（例如
document.querySelectorAll(".column")），用offsetHeight获取当前高度 - 找到最短列索引，将新元素
appendChild进去 - 若需“跨行”，计算目标高度：
baseRowHeight * spanCount（注意：必须是固定行高或可预测的最小高度） - 直接设置
el.style.height = baseRowHeight * spanCount + "px"，避免用min-height干扰列高比较
用 position: absolute + JS 定位会破坏流式可访问性
有人尝试用绝对定位模拟跨行，通过 JS 计算 left/top 把元素“摆”到指定行列位置。这看似灵活，但带来三个硬伤：
- 元素脱离文档流，屏幕阅读器无法按视觉顺序读取，
tab键焦点乱序 - 打印样式、缩放、字体加载完成前的重排都会错位
- 无法响应父容器
resize，必须监听并全量重算，性能差
除非是纯展示型画布（如数据看板），否则不建议走这条路径。
立即学习“前端免费学习笔记（深入）”；
真正要小心的是图片加载导致的高度塌陷
JS 插入元素时如果包含未加载完的图片，offsetHeight 会返回 0 或错误值，导致列高判断失准，后续元素全部挤进同一列。必须等图片就绪后再更新列高：
- 对每个新插入的
<img>绑定load事件（注意也要处理error） - 在回调里重新调用列高检测函数，并触发一次“补位”逻辑（把因高度突变而溢出的元素重新分配）
- 更稳妥的做法：统一用
img { display: block; min-height: 120px; }占位，再用object-fit控制内容，减少抖动
跨行逻辑本身不难，难的是让高度计算在异步资源、字体加载、用户缩放等现实条件下保持稳定。别省略图片加载状态管理，这是线上瀑布流最常见的崩坏点。
