纯 CSS Grid 无法可靠实现 Pinterest 瀑布流，因其 grid-row 跨行需预设高度，而卡片高度由异步图片等内容动态决定；必须结合 JS 动态分配卡片至最短列，并监听图片加载、ResizeObserver 等确保列高实时准确。
纯 CSS Grid 无法可靠实现 Pinterest 风格的“不等高元素 + 跨行自适应”瀑布流。Grid 的 grid-template-rows 是静态定义的，rowspan（即 grid-row 跨行）必须在布局前就明确写死，而 Pinterest 类布局的核心是：每个卡片高度未知、图片异步加载、列高实时变化、新卡片总往最短列追加——这天然需要 JS 参与调度。
为什么 grid-row: span N 在瀑布流里不实用
Grid 的跨行依赖预设行高或 minmax()，但 Pinterest 卡片高度由内容（尤其是未加载的 <img>）决定，JS 插入时 offsetHeight 常为 0；强行用 grid-row: span 2 会导致：下方卡片被顶开错位、列高比较失效、滚动时反复重排。这不是 Grid 的缺陷，而是语义错配——Grid 适合结构稳定、行列可枚举的布局，不是运行时动态平衡的流式容器。
真正可行的混合方案：CSS Grid 做列容器 + JS 管理卡片分配
放弃让 Grid 直接托管所有卡片，改用 Grid 控制“列容器”，再用 JS 把卡片 appendChild 到最短列中。这样既利用 Grid 的响应式列管理能力，又保留 JS 对高度的实时掌控：
- 父容器设
display: grid，用grid-template-columns: repeat(auto-fill, minmax(300px, 1fr))自动分列 - 每列是一个
<div class="column">，Grid 只负责它们的宽度和间距，不碰内部卡片 - JS 每次插入新卡片前，遍历所有
.column的offsetHeight，找到最小值对应列，再column.appendChild(card) - 必须监听图片加载：
card.querySelector('img')?.addEventListener('load', updateColumnHeights)，否则高度塌陷会连锁崩坏
图片加载未完成导致的列高误判怎么破
这是线上瀑布流 80% 崩溃的根源。JS 获取 offsetHeight 时，若 <img src="..."> 还没解码，返回值就是 0 或默认占位高度，后续所有卡片全挤进同一列：
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
立即学习“前端免费学习笔记（深入）”；
- 不要依赖
onload后单次更新——要触发“补位”：把已错位的卡片重新按最新列高分配一次 - 给图片加 CSS 占位：
img { display: block; min-height: 180px; background: #f5f5f5; }，避免高度跳变 - 更稳的做法：统一用
loading="lazy"+decode()预加载，再读高度：await img.decode(); return img.offsetHeight;
用 ResizeObserver 替代 window.resize 监听列宽变化
用户缩放、侧边栏折叠、字体加载完成都会改变列宽，但 window.addEventListener('resize') 完全感知不到这些内部变化：
- 对每个
.column实例化ResizeObserver，监听其contentRect.width - 宽度变化后，重新计算列数并清空重排（注意防抖，避免高频触发）
- 别用
getComputedStyle(el).width——它返回字符串，且可能含小数，要用Math.round(parseFloat(...))再比较
最复杂的点不在算法，而在时间线控制：图片加载、字体就绪、用户缩放、容器 resize 全是异步事件，它们的完成顺序不可预测。任何一步没对齐，列高数组就失真，整个瀑布流就偏航。别省略 loading 状态管理，这是唯一能守住底线的环节。
