编辑确认上传成功，其他人却仍看到旧图，可能涉及地址、引用与多层缓存。潍坊企业维护外贸网站时，先保存实际请求的完整路径和响应，再安排修复。不要在没确认对象前反复覆盖原件，也不要仅凭一台设备的显示判断所有用户状态。
只读示例，请替换为自己有权检查的公开资源
curl -sS -D - -o /dev/null https://example.com/assets/sample.webp
记录：实际地址、状态、Content-Type、Cache-Control、ETag或Last-Modified（若提供）。
这些头信息是线索，不单独证明所有缓存已刷新。先判断是不是同一个资源
页面可能使用生成的缩略图、另一份文件或旧引用。直接检查上传文件正确，并不能证明组件实际加载了它。先从公开页面确定所用地址，再比较文件身份与内容，避免把引用问题误当作缓存问题。
| 层次 | 要保存的事实 | 不宜推断 |
|---|---|---|
| 页面引用 | 当前实际资源网址 | 文件名相似就相同 |
| 来源响应 | 实际内容与响应头 | 一个节点代表所有用户 |
| 中间缓存 | 当前配置及可见响应 | 一定存在或一定已清除 |
| 浏览器显示 | 设备、缓存与复现条件 | 本机正常即全部正常 |
更换内容也要维护版本关系
- 保存旧新对象与受控原件。
- 先用只读方法确定实际目标和响应。
- 按已经确认的缓存配置作小范围处理。
- 复测代表设备、入口与相关尺寸，保留例外。
不要用随机参数掩盖资料管理
有计划的版本网址可以帮助部署，但反复手加随机字符串也可能留下大量失控引用。团队应确定资源身份与更新规则，并让模板使用一致版本。文件内容变成另一个产品时，更需要说明关系，不应只靠缓存刷新让旧说明悄悄指向新对象。
强制刷新后正常，能说明原因已经找到吗？
只能支持该条件下的观察，还应确认引用、响应与可复现范围。
换一个文件名总能解决吗？
可能改变引用与缓存路径，但仍需核对资料身份、旧入口及维护成本，不能代替根因分析。