Spine 换了 PNG 还显示旧外观？对齐源文件、线上文件和加载版本

本地PNG已经更新，线上角色却像没换过。先保存三份证据：准备交付的源文件、线上同一资源地址返回的文件，以及运行项目实际请求的地址。文件名相同、请求返回200或预览看起来相近，都不足以证明三者是同一版本。

先确认运行时真正请求了谁

记录最终URL、重定向链、资源批次和Atlas页名，不只记录上传按钮旁边的文件名。相对路径解析可能落到另一个目录；这部分先参考图集页URL定位。

在不暴露签名参数的前提下，比较可用文件的大小与内容摘要。大小相同不代表内容相同；摘要需要由实际字节计算，不能只读文件名中的一串字符就称已验证。

用三条分支缩小范围

• 本地源图是新内容，线上文件仍是旧内容：先检查上传目标、发布批次和服务端或边缘缓存，不只清本机缓存。
• 线上指定地址是新内容，但运行项目请求了旧地址：检查导出引用、配置或加载器持有的资源对象。
• 源图、线上文件和实际请求内容一致，画面仍不符合预期：继续核对真正显示的皮肤、附件和图像映射，不再把缓存当成唯一解释。

这些是诊断分支，不是本文已在用户工程中复现的故障。若无法取得运行时实际资源，先把证据缺口记下来，不用“强刷后偶尔正常”代替定位。

304不是没有加载成功，ETag也不一定是文件摘要

MDN缓存指南说明，条件请求得到304时，客户端可继续使用已存储的表示；这不是一次新的完整图片响应。ETag由服务端生成，可能使用内容摘要，也可能采用版本编号，不能默认把它直接当SHA校验值。

记录Cache-Control、ETag或Last-Modified及请求条件，结合实际版本解释。单次受控刷新可帮助对照，但不意味着已经定位所有CDN、加载器或内存对象的缓存。

修复后让整套引用落在同一批次

若采用带版本或内容摘要的资源URL，内容变化时按既有发布规则更新引用；Atlas和页图也要匹配，不只单独改一个PNG地址。不要每帧追加随机参数，也不要未经评估就让整个网站的静态资源失去缓存。

在Spine工作台按教程保留素材与导出批次，再由接收项目复验最终请求和画面。本文不宣称当前工作台有旧图故障，也未执行缓存工程实验；三种配色封面不是版本更新前后对照。