全球图片资源分发的缓存架构设计，难点不只是让图片离用户更近，还要保证各地拿到的版本一致，并在缓存未命中或失效时保护源站。头像、商品图、地图瓦片等场景都可能遇到旧图残留、缓存键冲突和回源流量骤增；设计时应先区分哪些内容允许短暂陈旧，再决定缓存与更新策略。
先把缓存对象和缓存键定义清楚
同一张原图可能生成缩略图、不同格式或不同尺寸。缓存键若只包含文件路径，却忽略尺寸、格式等会改变响应内容的参数，用户就可能拿到错误变体。反过来，若把无关参数也纳入键中，参数组合会制造大量重复缓存，降低命中率。
制定键规则时，明确路径、必要查询参数及内容协商规则；统一参数顺序和默认值，并让生成端与分发端使用同一套规范。身份相关图片应与公开图片分开缓存，不能让个性化响应进入公共缓存。全球图片资源分发的缓存架构设计还应检查不同地区是否采用一致的键规则，避免边缘节点之间表现不同。
用版本化发布降低旧图风险
覆盖原文件并继续沿用旧地址，容易出现部分节点已更新、部分节点仍提供旧内容的情况。较稳妥的方式是为内容变更生成新文件名或版本标识：先上传新图片并确认源站可读取，再更新引用它的页面或清单。旧版本可保留一段兼容时间，避免仍打开旧页面的用户突然遇到图片缺失。
对允许长期缓存的不可变文件，可设置较长的 Cache-Control 缓存期限；内容可变但地址不变时，则应缩短新鲜期，并结合 ETag 与 If-None-Match 等条件请求验证。两者侧重点不同：版本化地址减少逐节点清理的依赖，条件验证则能在内容未变时减少重复传输，但仍需要访问源站确认。
失效传播与回源保护要一起设计
清理缓存不等于所有地区同时更新
全球节点的失效传播可能有延迟；批量清理大量对象，也可能让节点短时间集中请求源站。先确认平台的失效范围、完成状态和失败反馈，再用少量对象验证结果。对可版本化的图片，优先切换新地址；只有必须沿用原地址时，再谨慎执行定向失效，并预估回源压力。
缓存未命中时避免请求叠加
热点对象过期或被清理后，大量并发请求可能同时回源，这种现象常称为惊群。可采用请求合并，让同一节点针对同一缓存键只发起一次回源；对短暂失效的热门对象，可设置有限的陈旧内容服务窗口，同时后台刷新。负缓存可减少重复请求不存在文件的压力，但应只用于确认的 404 等结果，并设置较短期限，避免刚上传的图片仍被当作不存在。
上线前按步骤验证
列出图片类型、变体参数、是否含用户私有内容，以及可接受的陈旧时间。
检查缓存键是否覆盖所有影响响应的参数，并用不同尺寸、格式分别请求，确认互不串图。
发布一张新版本图片，分别从多个地区请求新旧地址，检查响应内容、缓存状态和验证请求。
模拟热门图片过期或单个源站对象暂时不可用，观察回源并发、错误重试和陈旧内容策略。
记录命中率、回源请求数、回源错误率及各地区内容版本差异；出现异常时先区分键错误、失效延迟与源站故障。
全球图片资源分发的缓存架构设计，应把一致性目标落实到版本规则、缓存键和失效流程，再用回源保护措施处理流量波动。图片允许短暂陈旧时，可优先提高缓存复用并平滑刷新；要求及时更新时，则应采用新版本地址或可验证的更新机制，而不是单纯依赖大范围清缓存。
常见问题
旧图片通常从哪里来？
常见原因是原地址被覆盖，但部分节点仍缓存旧响应，或不同变体共用了缓存键。
版本化地址是否还需要清理缓存？
多数情况下，新版本使用新地址即可；旧地址仍可按兼容需求保留或逐步失效。
负缓存应该设多长？
没有适用于所有场景的固定时长。图片可能刚上传时应设得更短，并依据上传流程和源站恢复速度调整。
怎样降低失效时的回源峰值？
采用请求合并、分批失效和有限的陈旧内容服务，并持续观察源站并发与错误率。
