图片加载完成检测

问题：布局抖动的根源是「图没齐」

名片墙、附件墙这类按图片高度排版的布局，最常见的抖动问题：容器刚渲染完，脚本立刻读取每张图的高度，但此时图片还没下载完，拿到的是占位高度或 0。等真图陆续到位，已排好的版式又被推翻重算——用户看到的就是元素乱跳。

另一种隐蔽的坑是慢图：网络差时某张图迟迟不返回，基于图片数的回调可能永远等不到，或者回调触发时仍有图在传输中，布局只完成一半。

核心思路：等 all-done 信号再排版

该技能的解法很直接：先把列表数据渲染进容器，等容器内所有 img 都进入终态后再测高、做瀑布流。

• 底层依赖 imagesloaded，对容器内的 img 统一监听
• 关键在 always 回调：无论图片加载成功还是失败都算「完成」，失败的图不再阻塞布局，避免卡死
• 典型流程：npm i imagesloaded → 渲染列表 → await whenImagesReady(wallEl) → 再测布局
• 它与懒加载是互补关系：先让图片进入视口触发请求，再等加载完成的确认信号，两个阶段分开处理

适用边界与注意点

适用场景：卡片墙按图排版、Demo 瀑布流防抖动、打印预览前确认图片就绪。

不要做的事：

• 不要只监听 progress 事件就当全部完成——progress 只表示「还在进行」，不等于「都结束了」
• 不要和 lozad 抢同一套「未进视口不加载」的逻辑却不区分阶段：懒加载管的是「何时发起请求」，本技能管的是「何时算完」，混用会导致阶段错位
• 实现要点注释需标 小四原创，区分该写法与社区通用方案的差异

自测要点：用慢图验证不会提前算高；构造坏图（404）确认其也进入 always，布局不被单张失败的图拖住。

该技能不负责 CDN 分发或图片压缩，只回答一个问题：图到底什么时候算加载完。