真瀑布流必须动态插入最短列，column-count仅静态分栏且无法应对异步加载；grid需预知高度才能生效；js实现关键在load时机、列高维护与错误容错。
真瀑布流不是靠 column-count 拉个样式就完事的——它必须保证新图片总插进当前最短列，否则加载错乱、留白严重、移动端列高塌陷，全是坑。
为什么 column-count 不是真瀑布流
浏览器按文档流顺序切片分栏，不关心每列实际高度。哪怕加了 break-inside: avoid，也只能防止单张图被截断，无法解决列高不均导致的底部参差或大片空白。图片异步加载时占位高度为 0，后续元素直接“掉下去”，视觉完全错位。
-
column-count适合服务端已知宽高、静态内容、且能预设aspect-ratio或内联height的场景 - 响应式切换列数（如从 3 列变 2 列）需 JS 监听
resize并手动改style.columnCount，纯 CSS 媒体查询支持不稳定 - DOM 顺序 = 渲染顺序，无法按“最短列优先”重排，语义和 SEO 友好但逻辑失控
用 display: grid + grid-auto-flow: dense 靠谱吗
现代浏览器下可行，但有硬性前提：每张图必须带明确的 grid-row 跨行声明，而这个跨行数得靠 JS 根据原始宽高比换算——也就是说，你仍需预加载或服务端传尺寸，否则所有图都挤在第一行。
-
grid-template-columns: repeat(auto-fill, minmax(300px, 1fr)))控制列宽，比固定3更适应响应式 -
grid-auto-flow: dense只在有空缺格子时才填空，若所有项都指定了grid-row-start，它就不生效 - 没预设高度时，
img渲染高度为 0，grid-row: span 1就等于“占一行但没高度”，布局照样崩
JavaScript 手动实现“最短列优先”的关键点
核心不是“怎么插入”，而是“什么时候更新高度”和“怎么避免重复计算”。重点不在算法多炫，而在时机和容错。
- 监听每张图的
load事件，而非DOMContentLoaded—— 图片未加载完时高度为 0，提前算等于白算 - 列容器必须是真实 DOM 元素（如
<div class="col">），不能用绝对定位模拟，否则可访问性和打印样式全废 <li>原始尺寸未知时，用 <code>new Image()预加载获取naturalWidth/naturalHeight，再按目标列宽等比缩放，得出渲染高度，避免回流 - 滚动加载新图时，别重置
columnHeights = []，应在已有列高数组中继续找最小值并累加 - 给
img绑定onerror，fallback 到默认占位图，并手动调用一次插入逻辑 - 每次插入后，用
Math.max(...columnHeights)更新容器min-height，别依赖scrollHeight—— 它在某些浏览器里不准 - 懒加载场景下，首次计算前先用
getBoundingClientRect()确保容器已渲染，否则offsetWidth可能为 0
容易被忽略的细节：图片加载失败和容器高度
没人提但一上线就炸：图片 404 或 CORS 报错时，load 不触发，error 也不一定捕获到，列高数组就永远卡住；容器高度不随列高增长，会导致底部内容被遮挡或滚动异常。
