网站图片替换后仍显示旧图，先不要连续清缓存。问题可能是文章没有保存新引用、上传目标不是实际文件，也可能是浏览器或中间缓存仍提供旧内容。不同原因对应不同处理，混着修改会让排查越来越难。
网站图片更新缓存的核对应从“页面实际取哪张图”开始，再确认这个地址上的文件内容。只有引用和文件都正确，才进入缓存判断。换地址也不是万能方案，它需要与版本记录和所有使用位置一起维护。
先找实际引用，而不是只看后台文件名
打开出现旧图的真实页面，确认具体位置：封面、正文、背景或手机独立图。不同位置可能采用不同字段，后台替换了封面，不会自动改变正文。先把问题范围缩到一个位置。
接着由具备权限的实施人员查看该位置实际引用的资源地址。编辑器里显示的名称、本地文件名和浏览器最终加载地址未必相同。应记录完整的公开资源路径，再与本次计划更新的清单比较。
例如，假设正文仍引用旧版本地址，而新图上传到了另一个位置，清浏览器缓存无法修正这种关系。应更新正文引用，保存后重新打开，确认页面采用新地址。
背景图片与普通正文图也可能采用不同实现。页面上的背景没有更新，修改编辑器正文图片自然不会生效。先让实施人员指出当前模块使用的资源入口，再按该入口处理，避免内容人员在无关字段中不断换图。
如果使用响应式图片或图片服务，桌面和手机可能取得不同候选。不能只看默认地址，还需确认当前设备实际加载的文件。桌面已经更新、手机仍旧，可能是候选版本没有同步，而非手机缓存一定有问题。相关操作可参阅《官网图片怎么优化？不是压得越小越好：清晰度、加载速度、SEO 和无障碍要一起解决》。
排查记录可以简单写成“哪个页面、哪个位置、当前地址、期望版本”。这比一句“图片没换成功”更可操作，也能防止同名图片或多个文章混淆。
核对地址上的文件是否真的改变
找到实际地址后，再比较它提供的画面与当前发布文件。若地址本身仍返回旧内容，问题可能在上传位置、覆盖结果、派生图片或服务器侧处理，需要继续查实，不应只让访客刷新。
原址覆盖时，上传工具的成功提示可能只代表写入某个路径，并不能证明它就是页面引用位置。目录、大小写、子目录或同名文件处理都可能影响结果。核对目标路径，比反复上传同一文件更有价值。
同名文件的替换规则也要看工具真实行为。有些上传生成新路径，有些覆盖旧文件，有些拒绝重复名称。不能凭一次成功提示推断规则。可以在隔离位置用受控样本确认处理方式，再为正式资源选择对应操作。
如果系统会重新生成缩略图或格式版本，还要确认这些派生资源何时更新。原图已替换，不代表生成图自动变化；有的流程需要重建，有的有自己的版本标识，按实际系统处理。
可以保留一个可辨认的新版本特征，用于受控比较。例如构图变化、主体位置或独特画面元素，帮助检查当前取得的究竟是哪一版。不要只凭文件大小改变便认定内容正确。
文件存在与文件可用也不同。替换后的格式、编码或权限若不正确，页面可能显示失败或回退资源。应打开实际发布文件，确认内容与可加载性，再查看页面采用的结果。
再区分浏览器缓存与中间缓存
浏览器可能在本机保留资源；服务器前的缓存或图片服务也可能提供之前的版本。HTTP缓存规则控制何时复用和重新检查内容，但实际网站的层级与策略需要实施人员查看，不能仅按常见配置猜测。相关操作可参阅《企业网站上线流程：域名、服务器、证书、缓存与验证清单》。
先比较普通加载和受控的新浏览会话。新会话显示新图而原会话显示旧图，是定位本地缓存的线索；所有设备都旧，则继续核对中间层与文件。这个比较不能单独证明最终原因，却能缩小方向。
开发者工具中的资源请求信息，可以帮助确认实际地址、响应和是否复用缓存。运营人员不必理解所有头字段，但可以请实施人员基于同一位置给出证据，避免只凭“应该是缓存”结束。
在排查期间固定一个已确认的新版本，不要边查缓存边修改画面。否则第一次请求取得版本甲、第二次取得版本乙，比较结果可能只是文件又变了。保持资源内容与目标地址稳定，可以让缓存证据更容易解释。
清缓存应按范围进行。如果只是一张图片，优先确认针对该资源的刷新或清理方式。清整个网站缓存可能影响更多页面，也不会纠正错误引用或未生成的新版本。
不要要求所有访客手动清浏览器缓存作为长期更新策略。测试人员能够通过强制刷新看到新图，只证明这一种操作取得了新内容；普通访问是否能按预期更新，仍要另外核对。
原址覆盖与换版本地址分别适用
原址覆盖保留相同地址，适合系统已有清楚更新机制，且所有引用应同时采用最新画面的场景。它需要配合实际缓存更新，避免同一地址长期对应不稳定内容。
换版本地址则让新图片使用独立资源路径，旧地址仍对应旧文件，便于追溯和恢复。若系统采用版本化或内容标识方式，可以按既有流程生成并更新引用，而不是随意给每次上传加一个无法解释的名称。
两种方式没有一个对所有官网都更好。共享Logo或需要固定引用的资源，与文章独立配图的维护目标不同。先确认是否要让所有位置一起变化，再选择策略。
加查询参数有时可用于版本管理，但是否形成独立缓存键取决于实际服务规则。不能随手在地址后加随机数字，就承诺所有缓存都会更新。版本应稳定且有记录，避免每次访问都生成新值造成无意义请求。
共享资源换地址时，应列出需要更新的引用位置。某处遗漏旧地址，可能不是缓存传播慢，而是该页面仍按原清单工作。相反，原址覆盖会让全部共用位置跟着变化，要先确认这正是希望的范围，避免无关页面的视觉一起改变。
如果换新地址，还要更新真正使用它的位置和候选资源。仅上传新文件，页面仍引用旧地址，结果不会改变。版本策略应包含生成、引用、保存与核对，而不是只改变命名。
用新旧访问条件验证正常显示
先保留一份更新清单：旧地址、新地址或原址覆盖范围、目标页面、图片用途和期望版本。验收人员据此确认实际画面，不依赖记忆猜测“看起来像新图”。
若更新包含多档尺寸，可以按不同显示条件抽查实际选中的候选，并在清单标明已核对范围。无需为每个像素宽度重复测试，但关键裁切、手机独立图与桌面图都应有对应检查，不能只确认最大文件已经改变。
分别在曾经访问过的设备和新的访问环境中打开。查看普通加载结果，确认常规路径能取得预期版本。再核对手机与桌面候选、文章列表与正文，避免只检查一种设备或模块。
返回旧页面、重新加载和打开分享链接，也要按照实际用途测试。如果换了地址，确认保存记录确实新引用；如果原址覆盖，确认普通访问按约定更新，不要求每人都执行特殊操作。
发现差异时记录当前地址和访问条件，不急于再次覆盖。这样才能区分更新未传播、候选遗漏与引用错误。每轮调整后用同样样本复核，避免连续换图使原问题证据消失。
成功标志是所有约定使用位置采用正确版本，实际资源可加载，正常访问能够更新，旧版本仍按维护安排可追溯。图片更新不应以“我强制刷新后看到了”作为唯一结论。
常见问题
强制刷新能看到新图，就说明更新结束了吗？
还不够。需要确认普通访问和约定设备能够按策略取得新版本。特殊刷新有助于定位问题，不能替代正常访客路径的验收。
所有设备都显示旧图，一定是服务器缓存吗？
不一定。实际引用可能仍旧，上传位置或派生文件也可能错误。先确认地址与文件，再核对中间缓存，不宜直接猜测原因。
换文件名就能解决全部旧图问题吗？
只能解决部分情形。新资源还需要正确上传并更新所有引用和候选。文章未保存新地址，或其他位置仍旧时，换名称不能自动完成任务。
原图换了，为什么手机还是旧图？
手机可能采用独立裁切或响应式候选。检查当前设备实际加载的文件，确认派生版本是否更新；不能仅凭桌面正常就让用户清缓存。
更新后能不能立刻删除旧图片？
先核对共用引用和恢复安排。版本化资源可能仍被旧文章或历史记录使用，清理应依据实际关系，而不是只看最新页面已经换图。
链接复制成功
