真实项目中瀑布流布局必须用 JavaScript 实现（如 Masonry），因 CSS Grid 在图片懒加载后无法自动重排导致列高不齐；需配合 imagesLoaded 钩子、手动控制懒加载时机、IntersectionObserver 触发加载、批量布局及 Safari 兼容处理。
瀑布流布局用 CSS Grid 还是 JavaScript 实现？
纯 CSS 实现的 column-count 或 grid-template-columns: repeat(auto-fill, minmax(300px, 1fr)) 看似简单，但对图片高度动态、内容不均的场景会错位——尤其当懒加载触发后图片撑开容器，Grid 无法自动重排，导致列高严重不齐。所以真实项目里，必须用 JavaScript 控制布局逻辑，比如 Masonry（官方库）或轻量 vanilla-masonry。
关键点：
-
Masonry支持imagesLoaded钩子，可等图片加载完再布局，避免闪动 - 不要用
float+clear旧方案，兼容性和响应式支持差 - 若用
CSS grid，务必配合grid-auto-flow: dense和固定行高（不现实），否则懒加载后列底边会撕裂
图片懒加载怎么和瀑布流同步触发？
直接给 img 加 loading="lazy" 不行：浏览器原生懒加载在视口滚动时才触发，而瀑布流容器本身可能高度不定，IntersectionObserver 触发时机和 Masonry 布局节奏不同步，常出现“图片加载完成 → 容器高度突变 → 下方项被顶出视口 → 再次触发懒加载”的循环。
正确做法是把懒加载控制权交给 Masonry 实例：
立即学习“前端免费学习笔记（深入）”；
- 初始化时所有
img的src放在data-src，src留空或设为 1×1 占位图 - 用
Masonry的layoutComplete事件，在每次布局结束时，只对当前可视区域内的img[data-src]批量赋值src - 赋值后手动调用
img.addEventListener('load', () => masonry.layout())，确保高度更新后立刻重排
滚动加载更多时如何避免重复布局和卡顿？
用户快速滚动时，scroll 事件高频触发，如果每次都在回调里调用 masonry.append(...) + masonry.layout()，会导致大量重排、内存泄漏、甚至浏览器冻结。
实操建议：
- 用
IntersectionObserver监听“加载更多”占位元素（如div#load-more-trigger），而非监听window.onscroll - 新数据插入前先
masonry.remove(newElements)清掉旧 DOM 引用（防止内存堆积） - 批量追加节点后，只调用一次
masonry.append(elements).layout()，不要对每个 item 单独 layout - 给
masonry配置transitionDuration: 0，关闭动画——瀑布流动画在滚动中反而加重卡顿
移动端 Safari 上图片加载后布局错乱怎么办？
Safari 对 img 的 naturalWidth/naturalHeight 读取有延迟，尤其 WebP 或 CDN 压缩图；Masonry 在图片还没解析出尺寸时就计算了高度，导致后续撑开错位。这不是 bug，是渲染管线差异。
绕过方式很实在：
- 给所有
img设width和height属性（服务端能算出宽高比的话，用aspect-ratio更稳） - 加载后用
getBoundingClientRect()代替naturalHeight获取真实渲染高度 - 在
img.onload回调里加setTimeout(() => masonry.layout(), 16)，让浏览器至少走完一帧再重排
最麻烦的其实是图片宽高比丢失——一旦后端返回图没带尺寸信息，前端又没 fallback，Safari 就只能靠 guess，这时候错位几乎不可避免。所以服务端提供 width/height 字段，比前端补救更可靠。
