IntersectionObserver实现真正预取需动态rootMargin、img.decode()等待、WeakMap+Map双重去重及滚动趋势预测，而非仅监听isIntersecting。
直接用 IntersectionObserver 监听 isIntersecting 就开始加载图片？那不是预取，是懒加载，而且大概率用户已经看到白块了才触发解码——真正的“感知式预取”，核心是让资源在用户**还没滚到**、但**极可能马上看到**时就准备好。
rootMargin 不是可选项，是预取时机的唯一控制开关
threshold 只能告诉你“当前可见比例”，对“即将进来”毫无意义；isIntersecting 为 true 时元素已入视口，网络+解码延迟会让首帧卡顿。只有 rootMargin 能把判定边界外推，制造时间缓冲。
- 桌面端常用
"300px"（对应中速滚动约 300–400ms 提前量） - 移动端建议按设备 DPR 和滚动惯性动态设：例如
1.5 * window.devicePixelRatio倍屏幕高度的 15% →${Math.round(window.innerHeight * 0.15)}px - 三折叠设备（如 Mate XT G 态）必须监听
resize，重算rootMargin，否则展开后原值失效 - 切忌写死
"0px"或"50px"：慢网下 50px 不够解码，快滑时 300px 又导致过度预取
WeakMap + 全局 URL Map 是去重的双保险
一个 observe()。不加控制会并发发 5 次相同 fetch，CDN 限流、带宽浪费、内存泄漏全来。
- 用
WeakMap缓存每个 DOM 元素的预取状态，元素卸载自动 GC; timestamp: number }> - 另用
Map对同一> data-src做全局去重：首次请求返回Promise，后续直接.then()复用 - 预取前先查 WeakMap：若
promise存在且未 reject，直接return promise；若已 resolve，跳过 fetch，直接赋img.src - 并发数硬限制为 3：内部用
Promise.allSettled(queue.slice(0, 3))，避免突发滚动压垮网络栈
滚动趋势预测比像素阈值更贴近用户意图
纯靠 rootMargin 是静态策略，但用户滚动有惯性。向下猛划时，应加大预取范围；向上回滚时，应收缩甚至暂停——这需要轻量级行为感知，而非重计算。
- 仅用
scroll节流采样（50ms 间隔），记录最近两次deltaY符号和幅度，不参与加载逻辑，只调参 - 连续两次
deltaY > 0（向下滚动）→ 动态将rootMargin从"200px"扩至"400px" - 检测到
mouseenter到轮播图/放大镜区域 → 立即触发该容器内所有[data-prefetch]图片的预取，无视 observer 当前状态 - 切勿在滚动中实时重置整个
IntersectionObserver实例：先unobserve()再observe()会丢掉 pending entries
img.decode() 是预取完成的真正信号，不是 src 赋值那一刻
很多实现一拿到 fetch 响应就立刻 img.src = url，结果浏览器还在解码，load 事件没触发，offsetHeight 仍是 0 —— 这会导致布局抖动、CLS 指标恶化。
- 必须等
img.decode()Promise resolve 后，再赋src并触发布局（例如移除loadingclass） -
decode()失败需降级：catch 后仍赋src，但标记该 URL 为“不可 decode”，后续同 URL 不再调用decode() - 对 WebP/AVIF 图片，
decode()耗时明显长于 JPEG，预取队列里应优先保障它们的执行 slot - 注意 Safari 旧版本不支持
decode()，需用img.onload+img.naturalWidth > 0回退判断
真正难的不是写对 new IntersectionObserver，而是让预取决策随设备、网络、用户行为实时变化——rootMargin 动态化、decode() 必须等、去重必须跨模块，漏掉其中任一环，预取就会退化成加重负担的无效请求。
