真正可用的瀑布流方案是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 顺序彻底错位。
- 屏幕阅读器按 DOM 读，用户看到的是“图1、图2、图3”，听到的却是“图1、图4、图2”，违反 WCAG
- 搜索引擎抓取首屏内容时，可能把关键图排到第三列底部，影响 SEO
-
break-inside: avoid在图片未加载完成时失效：高度为 0，<img>被截断或挤进错误列 - 窗口 resize 或动态插入新项后，无法自动重排，必须手动触发 layout 强制刷新
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 这类手动跨行虽精确，但需预知每张图高度比例，实际中几乎不可维护。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
图片加载塌陷的硬解法：必须设占位，不能依赖 JS 补救
所有瀑布流抖动、跳变、错位，90% 源于图片加载前高度为 0。JS 补救（如监听 load 后调用 layout()）永远慢半拍，且在慢网下更明显。
- 服务端渲染时，强制输出
<img width="800" height="600">：现代浏览器（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">，不能直接写在<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 }，布局直接崩在第一步。
