CDN实时更新图片——刷新慢多半卡在这3个环节

图片文件名没动，内容换了，链接还是原来那条——用户截图过来，看到的还是旧的那张。这种时候十有八九不是图没传上去，是 cdn实时更新图片 这条链路里有个环节在按旧版本办事。CDN 本质上是个记性特别好的中间人，它认的是 URL，不认你后台点了什么上传按钮。越急着点刷新，越容易跳过真正卡住的那一层。

cdn实时更新图片卡住的第一个环节，是过期时间设得太长

打开响应头，找 Cache-Control 那行，max-age 后面跟一串大数字的，基本就是它。图片这类静态资源，不少模板一上来就给一年，图省事。页面 HTML 设短点没事，可图片目录跟着一起设成年，改图的时候就只剩刷新这一条路。比较稳的做法是把图片目录单独配：过期时间压短一些；或者直接让文件名带哈希，过期设长也不怕，文件名变了就是新的 URL。两种思路选一种，别两头都占着又互不配套，那才叫别扭。

顺带说一句 Expires 头，老服务器上常和 Cache-Control 一起出现，两个都写、还写得不一样，节点到底听谁的就得看具体实现了，拿不准就去翻服务商文档，以官方页面说明为准。

文件名没变，CDN 就当你没改过

缓存键基本就是 URL，有些服务商还会把查询参数算进去，也有些默认忽略。同一个路径同名覆盖，节点手上那份副本还在有效期内，它没有理由回源。改图最省事的办法是换名字：logo-2.png、banner-0901.jpg，页面里的 src 跟着改，老链接留着别删，别处可能还引用着。不想改名也行，加个版本参数，改一次加一次。这比一遍遍提交刷新靠谱得多，也不会把缓存命中率折腾下去。

源站自己也在缓存，这层最容易被忘掉

查了半天 CDN，最后发现源站那台机器上还挂着一层缓存，这种事不少见。Nginx 的 expires、面板自带的缓存插件、对象存储上的元数据，一个个都算数。还有几种更隐蔽的：回源 host 填错打到别的站上，回源协议 http 和 https 混着用，源站防盗链把回源请求挡在门外——节点拿不到新图，手里那份旧的只能继续撑着。判断方法不难，直连源站 IP 带 Host 拉一次，源站返回的也是旧图，那这条链路的问题就不在 CDN。

刷新提交成功，不等于大家都看到新图

页面提示提交成功，只是任务进了队列。刷新要下发到各个节点，节点多、地区散，快慢根本不齐。热门地区先好，小运营商和海外节点慢半拍，用户截图往往就来自后面这批。着急可以配预热，但别对着一堆图一次性全推，源站带宽容易被自己人打满。目录刷新更要谨慎，一个大目录刷下去，命中率掉一截，回源压力立马起来，能按单条 URL 刷的就别整目录。

几分钟判断卡在哪一环

本地终端敲 curl -I 图片地址，看三样：Age、Cache-Control，还有服务商常加的 X-Cache 或 Via，Age 表示这份副本在节点上躺了多久。多换几个网络环境再拉一次，手机流量和公司宽带各试一遍。手上有原图和线上图的，比文件大小或者算个 md5，一眼就知道是不是同一张。再把源站响应头和 CDN 响应头摆一起看，差异通常就指向问题所在。

几个反着来的操作，踩过一次就记住

把目录刷新当日常操作，天天来一遍，缓存等于没开；给图片加随机参数想强制更新，结果每次请求都是新 URL，命中率掉得厉害，用户端反而更慢；源站先把图删了再传，中间那几分钟正好有回源请求，日志里一串 404，节点缓存也跟着乱。还有一种更常见：图片改了，页面没改，HTML 那边缓存着旧的引用，用户看到的自然是旧图。正常的顺序是先传新文件、再改页面引用、最后按需刷页面，别倒过来。

回过头看，cdn实时更新图片慢，多半不怪刷新按钮不灵。先把过期时间多长、URL 有没有变、源站那层清没清这三处捋顺，刷新只是收尾动作，不是救命稻草。下次改图之前，花两分钟看一眼响应头，比事后反复提交刷新省事得多。