把 TTL（缓存存活时间）调长，并不一定能让更多请求命中缓存。如果同一份图片因无关参数被拆成多个缓存对象，或请求总被规则送回源站，延长 TTL 也帮不上忙。有效的CDN缓存命中率提升方法，应从缓存键和回源规则入手，再调整过期时间。
先确认命中率统计的是什么
缓存命中率通常按命中请求数占比计算，但不同平台也可能提供按传输字节统计的指标。前者反映请求是否由边缘节点直接响应，后者更能体现大文件缓存带来的回源流量节省。排查时先确认口径，并按路径、状态码、地区或内容类型拆分；全站平均值可能掩盖少数高回源目录的问题。
缓存键决定哪些请求能共用对象
缓存键通常由主机名、路径及部分请求参数或请求头组成。键中纳入的内容越多，缓存对象可能越分散；纳入过少，则可能把本应区分的内容错误地合并。
只保留会改变响应的维度
例如，商品主图的尺寸参数若确实对应不同图片，就应保留在缓存键中；追踪来源的参数若不影响响应，可以考虑从缓存键中排除。多语言页面若由语言请求头决定内容，则要明确区分语言版本，或改由路径标识语言。评估时逐项核对参数、Cookie 和请求头：它们是否会改变响应正文或权限？如果不会，就不应无条件制造新的缓存变体。
这也是CDN缓存命中率提升方法中容易被忽视的一步。不要为了追求更高命中率，删掉影响内容或用户权限的键字段；公共资源和个性化页面应分别制定规则。
回源规则要区分可缓存与必须绕过的请求
公开的版本化图片、字体和安装包通常适合缓存；带有用户身份的账户页面、购物车或私有接口则通常不应被公共缓存。检查规则时，重点找出因 Cookie、授权信息、查询参数、请求方法或响应状态而绕过缓存的条件。规则过宽会让公共内容也频繁回源，规则过松则可能带来隐私和数据串用风险。
回源行为还受源站响应头影响。常见的 Cache-Control 指令可以表达是否允许缓存及缓存时间；若源站返回禁止缓存的指令，边缘规则是否覆盖它，必须有明确设计和安全依据。TTL 可按内容更新频率设置：稳定的版本化静态文件可采用较长时间并配合换名发布；经常变化的公共内容可从较短周期开始，再依据更新延迟和回源压力调整。不存在适用于所有站点的固定值。
按顺序排查并验证调整
- 建立基线：记录请求命中率、字节命中率、回源请求量，并选取回源较多的路径。
- 检查缓存键：比较同一路径的参数、Cookie 和请求头，确认哪些差异实际改变响应。
- 审查绕过条件：找出规则中强制回源、禁止缓存和仅对特定状态生效的部分。
- 分内容试调：先调整一类公开资源，保留个性化和授权内容的保护规则。
- 验证新鲜度与安全：检查更新能否按预期生效，并确认不同用户不会收到彼此的私有内容。
若命中率上升，但旧内容长时间不更新，应同步完善失效机制：发布新版本时使用新的资源标识，或在确有需要时主动清除相关缓存。只清缓存而不修正缓存键和规则，问题往往会再次出现。
常见问题
命中率越高越好吗？
不一定。错误缓存个性化内容的风险高于命中率收益；应同时看回源量、内容新鲜度和缓存安全。
查询参数都要加入缓存键吗？
不必。保留会改变响应的参数，评估是否排除追踪等无关参数，并验证排除后不会返回错误内容。
延长 TTL 适合什么情况？
适合更新不频繁、且有可靠版本发布或失效机制的内容。动态内容则应先确认缓存边界和更新要求。
归根结底，CDN缓存命中率提升方法不是单纯拉长 TTL，而是让相同的公共内容使用一致的缓存键，让应缓存的请求留在边缘处理，让私有或不适合缓存的请求明确回源。