CDN图片实时更新，3个刷新环节最容易卡

图换了、刷新也点了，用户那边截图过来还是旧的那一张。cdn图片实时更新3个刷新环节最容易卡，这 3 个环节还不在同一个地方、不归同一个人管：一个在源站，一个在 CDN 边缘，最后一个赖在用户手机里。多数人只盯着中间那个刷新按钮猛点，点完没动静就开始怀疑服务商，结果另外两处压根没动过。

cdn图片实时更新3个刷新环节最容易卡：第一关先看源站换没换

别急着开控制台，先确认源站上的文件真的换了。我见过太多次，运营把新图传到测试目录，线上那个 bucket 还是旧的；或者图传上去了，但对象存储里同名覆盖失败，多了个 (1) 后缀，页面引用的还是老路径。还有一种更阴的：源站做了负载均衡，后面两台机器，运维只往其中一台推了新图，CDN 回源命中哪台全看运气，你刷新十次能拿到两种结果。这种情况你刷边缘刷到怀疑人生也没用，问题在源站自己就不一致。所以第一步永远是绕过 CDN，直接用源站地址加个随机参数去拉图，多拉几次，看是不是每次都一样、是不是新的。

Cache-Control 一句话，能让你白刷十次

图片这类静态资源，很多人配置缓存过期时间的时候手特别大方，一个月起步，有的直接一年。设的时候想着省流量省回源，出事的时候就知道疼了。刷新操作清的是 CDN 边缘那份副本，清不掉已经落到浏览器里那份。用户第一次拉图的时候响应头带着 Cache-Control: max-age=31536000，那这一年之内他本地都认旧图，你边缘刷成花也没用。而且源站响应头和 CDN 控制台里的缓存规则谁优先，各家产品不一样，有的是控制台规则覆盖源站头，有的是反过来，以服务商控制台或官方文档说明为准，别凭印象。真要频繁换图，与其跟缓存较劲，不如让每张图天生就是新地址——文件名带版本号，或者 URL 后面挂个 ?v= 参数，成本最低，效果最实在。

提交成功是提交成功，生效是另一回事

控制台上点刷新，返回一个任务 ID，那只能说明任务收下了。目录刷新和 URL 刷新是两码事，目录刷新一般额度更紧、有的还要走审核或排队，URL 刷新快一点但也有每日条数限制，超了就得等，具体配额以服务商说明为准。还有通配符的问题，很多人以为提交 /images/* 就能清掉整个目录，实际支持范围和匹配规则各家不同。刷新任务是异步的，提交完立刻去测大概率还是旧图，中间隔多久不好说，得看队列里堆了多少活。所以我从来不连点，点一次，记下时间，过一会儿再回头验证，顺手看下响应头里的 Age 有没有归零、X-Cache 是 HIT 还是 MISS。连点十次除了把配额烧光，什么也换不来。

浏览器和中间层，这两处的缓存最难清

手机端尤其顽固。微信内置浏览器、各家 App 自己的图片缓存库，都不太听话，有的干脆不完全遵守 Cache-Control，它会按图片 URL 自己存一份，URL 不变就一直给你看旧的。公司网络出口那层代理缓存也是一个坑，办公网里看着是旧图，切到手机流量就是新的，这种对比一试就知道问题不在 CDN。还有 CDN 和源站之间那层回源缓存，配置了回源跟随或者中间加了反向代理、WAF 的，链路比你想的长。排查这类问题有个土办法但特别好使：换设备、换网络、换没登录过的浏览器，三种都试一遍，能定位到是哪一个环节咬住了不放。

图片处理那一层，容易被整段忘掉

现在 CDN 基本都带图片处理，自动转 webp、按尺寸裁剪、加水印，全靠 URL 参数。麻烦在于处理结果是按参数化 URL 单独缓存的，你刷新了原图那个地址，带 ?imageMogr2 或 ?x-oss-process 的那一堆派生地址并不会跟着清。更细的还有参数顺序，a=1&b=2 和 b=2&a=1 在缓存眼里可能就不是同一个 key。所以换图之后发现缩略图还是旧的，别怀疑人生，先把页面里实际请求的那条完整 URL 复制出来，逐条提交刷新，或者更干脆——连参数一起换版本。

我自己顺手的一套顺序

顺序不重要，别扭着来就行：一、绕过 CDN 直连源站，加随机参数多拉几次确认新图；二、用 curl 看响应头，Cache-Control、Age、ETag、X-Cache 四个值记下来；三、提交一次刷新，记时间，别重复点；四、等几分钟再用 curl 看 Age 是不是重置了；五、换手机流量、换个没缓存过的浏览器再看；六、还不行就直接改文件名。走到第六步基本都能解决，虽然土，但它是所有办法里唯一不依赖任何缓存规则的。

最后还是那句话，刷新是救火用的，不是日常流程。图片天天换的业务，从一开始就把版本号写进文件名，让每次更新天然就是一个新 URL，边缘、浏览器、App 本地缓存全都不用管，也省得半夜被人叫起来排查。真碰上刷不掉的情况，按上面那条链路一处一处排，别在控制台里瞎点。