线上页面出现旧图片、错误配置或接口结果不一致时，cdn缓存刷新往往是排查手段之一，但直接执行全站清理并不稳妥。正确做法是先判断问题来自浏览器、本地网络、CDN节点还是源站，再选择合适的刷新范围。这样既能缩短恢复时间，也能避免大量请求同时回源。
先确认：问题是否真的与缓存有关
同一个网址在不同设备上表现不同，并不能立即证明是CDN缓存导致。可以先记录完整URL、请求时间、访问地区、运营商、状态码和响应头，重点观察 Age、Cache-Control、ETag、Last-Modified 等信息。不同CDN产品的响应头名称可能不同，应以实际控制台和文档为准。
- 只有个别浏览器显示旧内容：先清理浏览器缓存，或使用无痕窗口复核。
- 多个网络环境都显示旧文件，而源站已经更新：较可能需要执行cdn缓存刷新。
- 返回5xx、连接超时或源站日志没有请求：问题可能在源站、回源链路或安全策略，单纯刷新缓存通常无效。
- 只有某个带查询参数的地址异常：要检查CDN是否把查询参数纳入缓存键。
在操作前保存当前配置、异常URL和源站版本号。若页面涉及支付、登录或库存，先确认动态接口没有被错误缓存，避免把业务故障误判为静态资源问题。
cdn缓存刷新应按范围逐步扩大
第一步：锁定对象和刷新类型
常见方式包括按文件、按目录、按主机名和全站刷新。单个CSS、JavaScript、图片或HTML文件异常时，优先使用精确URL；同一目录下有一批发布文件异常，可考虑目录刷新；只有缓存规则整体错误、密钥泄露或大范围版本错乱时，才评估全站刷新。
按路径刷新影响较小、回源压力相对可控，但可能漏掉别名URL、带参数URL或其他主机名。全量刷新覆盖彻底，却可能在短时间内使大量请求回源，尤其是大文件、视频或访问量较高的站点。因此，cdn缓存刷新需要和资源类型、访问峰值及源站承载能力一起判断。
第二步：执行前检查源站
- 确认源站已经部署正确版本，并直接访问源站或临时回源地址核对内容。
- 检查文件路径、大小、MIME类型、压缩方式和缓存响应头，防止把源站错误重新分发到节点。
- 查看源站连接数、带宽、CPU和磁盘读取情况；无法确认承载能力时，不要在流量高峰贸然执行全量刷新。
- 在CDN控制台选择刷新对象，复核域名、路径和操作范围后提交，并记录任务编号或提交时间。
第三步：等待任务完成并验证
cdn缓存刷新通常不是所有节点同时完成，控制台显示提交成功也不等于每个边缘节点已经更新。等待时间受节点数量、刷新队列、资源类型和平台策略影响，常见情况是数分钟内开始生效，复杂或大范围任务可能需要更久。
- 从至少两个网络环境访问目标URL，检查正文、图片、脚本和响应状态。
- 用请求头或开发者工具确认返回内容的版本标识、ETag或Last-Modified是否变化。
- 观察源站回源请求、带宽和错误率，确认没有因刷新引发突发回源。
- 若仍有旧内容，核对是否存在多个域名、重定向地址、浏览器缓存或上游代理。
比刷新更稳的长期做法
对于静态资源，发布时采用文件名版本化通常比频繁清缓存更可靠，例如将 app.js 改为带构建版本或内容摘要的文件名，再更新HTML引用。旧文件可以保留一段时间，新文件使用新的URL，节点自然会按新地址获取内容。缺点是需要调整构建流程，并管理旧资源的保留周期。
HTML入口文件可以设置较短缓存时间，图片、字体和带版本号的脚本则设置相对更长的缓存时间；具体时长应结合更新频率和回源能力调整。不要把登录状态、购物车、订单结果等个性化响应按公共静态内容缓存。遇到跨地区或多运营商访问差异时，应分别验证解析、节点命中和回源结果，而不是反复执行cdn缓存刷新。
如果团队缺少专人维护CDN规则，或需要梳理刷新权限、回源策略和故障记录，可以了解德讯电讯这类提供网络与云服务支持的服务商，重点比较其适用的技术支持范围和运维流程，不应只依据宣传速度或单一价格判断。
常见问题
刷新后页面仍然没有更新怎么办？
先确认源站内容正确，再检查访问的是否为同一域名、路径和查询参数；同时排查浏览器缓存、反向代理和多级CDN。
可以直接做全站刷新吗？
可以，但应限于影响范围明确且源站有足够回源能力的情况。普通单文件问题优先按URL刷新，避免无谓增加源站压力。
刷新任务显示成功是否代表故障已恢复？
不代表。还要从实际用户网络验证内容、状态码和响应头，并观察一段时间的回源量与错误率。
为什么文件更新后还需要刷新？
如果文件URL没有变化，CDN可能仍按缓存规则返回旧对象。文件版本化或内容摘要命名可以减少对cdn缓存刷新的依赖。
总之，线上故障中的cdn缓存刷新应遵循“先确认、再小范围处理、最后验证”的顺序，并把源站检查、访问验证和长期版本化纳入同一套流程。
