真正可用的瀑布流方案是display: grid配合grid-auto-flow: dense，并通过aspect-ratio或padding-bottom解决图片加载塌陷；column-count因dom与视觉顺序错位、无障碍和seo问题不可用于生产。
纯 CSS 实现不等高图片瀑布流，column-count 看似最简，但生产环境基本不可用；真正可用的方案只有 display: grid 配合 grid-auto-flow: dense，且必须解决图片加载导致的塌陷问题。
为什么 column-count 在真实项目中会翻车
它把 DOM 顺序当文本流切分，第 1 个 <div class="item"> 出现在第一列顶部，第 4 个却可能落到第二列顶部——视觉顺序和 DOM 顺序彻底错位。
<ul>
<li>屏幕阅读器按 DOM 读，用户看到的是“图1、图2、图3”，听到的却是“图1、图4、图2”，违反 WCAG</li>
<li>搜索引擎抓取首屏内容时，可能把关键图排到第三列底部，影响 SEO</li>
<li>
<code>break-inside: avoid 在图片未加载完成时失效：高度为 0，<img> 被截断或挤进错误列
display: grid 模拟瀑布流的关键参数组合
不用 grid-template-rows: masonry（仅 Chrome/Edge 116+ 支持），靠 grid-auto-flow: dense + 自撑高 item 实现兼容性与效果平衡。
-
grid-template-columns: repeat(auto-fill, minmax(280px, 1fr))：小屏自动缩为 1 列，避免横向溢出 -
grid-auto-rows: 10px：设一个极小基准行高，让 Grid 知道“行存在”，否则dense模式无法调度跨行 -
grid-auto-flow: dense：允许短 item 填补前面长 item 留下的空隙，这是“瀑布感”的唯一来源 -
gap: 12px：统一控制间距，比margin更稳定，不参与基线计算
注意：grid-row-end: span 3 这类手动跨行虽精确，但需预知每张图高度比例，实际中几乎不可维护。
图片加载塌陷的硬解法：必须设占位，不能依赖 JS 补救
所有瀑布流抖动、跳变、错位，90% 源于图片加载前高度为 0。JS 补救（如监听 load 后调用 layout()）永远慢半拍，且在慢网下更明显。
- 服务端渲染时，强制输出
<img style="max-width:90%" style="max-width:90%">：现代浏览器（Chrome/Firefox/Safari 15.4+）会据此推导aspect-ratio，无需额外样式 - 客户端 fallback：
img { aspect-ratio: 4/3; object-fit: cover; }，覆盖绝大多数现代场景 - 绝对不要对首屏瀑布流 item 使用
loading="lazy"：它会让占位失效风险放大数倍 - 若需兼容 Safari ≤15.3，必须用
padding-bottom技巧，但要包裹一层<div class="img-wrapper">，不能直接写在 <code><img>上用 Masonry.js 时最容易忽略的三个细节
它能绕过浏览器限制，但默认行为和常见误配会导致定位偏移、事件错乱、性能骤降。
-
container父级若有transform或filter，Masonry 的position: absolute定位会失效——必须加contain: layout或改用will-change: transform重置包含上下文 -
itemSelector必须精确匹配子项，写成".item *"或".item > div"会导致 JS 找不到真实 item，布局全乱 - 动态添加新项后，用
layout.appended(newEls)，不是layout.reloadItems()：后者会清空全部缓存并重算所有项，性能差一个数量级
最常被忽略的一点：Masonry 初始化前，所有
<img>必须有显式宽高（哪怕只是占位值），否则getBoundingClientRect()返回{ height: 0 }，布局直接崩在第一步。 -
