命中率低时，直接延长缓存时间或忽略请求参数，看似能减少回源，却可能把旧内容、错误尺寸或不该共享的文件交给用户。图片和视频分发的缓存命中率优化方法，应先查明请求为何未命中，再按内容是否可变、是否私有、是否分片来调整规则。
先分清低命中的原因
查看边缘节点日志或缓存分析中的 HIT、MISS、BYPASS、EXPIRED 等状态，并按路径、状态码、请求参数和文件类型拆分。MISS 表示当前缓存没有对象；BYPASS 常与规则或请求条件有关；EXPIRED 则说明对象已过期或需重新验证。不同平台的状态定义可能不同，应以对应产品文档为准。
还要确认统计口径：按请求数计算时，小文件和重复访问会影响结果；按流量计算时，大视频文件的权重更高。全站平均值可能掩盖某类图片持续回源的问题。
哪些规则调整容易出问题
忽略查询参数
如果图片服务通过参数返回裁切、尺寸或格式不同的图片，例如同一资源分别请求宽度为 320 和 960 的版本，缓存键忽略尺寸参数就可能串图。只有确认某参数不影响响应内容，才考虑从缓存键中排除；签名、权限令牌等参数更不能未经评估就忽略。
把所有文件都设成长缓存
视频分片和图片通常适合缓存，但更新方式决定了可用时长。文件名不变、内容会覆盖时，较长 TTL 可能让旧版本停留在边缘；无法保证及时清除缓存时，应采用较短时长或验证机制。版本号随内容变化的资源更适合长缓存，但要同时确保页面或播放清单引用新版本。
混缓存清单、分片和个性化内容
HLS 等流媒体常见 .m3u8 播放清单与 .ts、.m4s 等媒体分片。清单可能随直播进度频繁更新，分片则通常在发布后保持不变，两者不宜简单套用同一 TTL。包含用户身份、付费权限或个性化水印的响应，也不应因共享缓存规则而被其他用户复用。
忽略状态码和 Range 请求
部分视频请求使用 Range 获取文件的一段，响应可能是 206 Partial Content。若缓存规则把分段响应与完整对象混为一谈，可能造成播放异常；错误地缓存 401、403、404 等响应，也可能让权限恢复或文件上线后仍显示旧错误。应检查平台对分段缓存及错误状态的处理方式，并限制错误响应的缓存时间。
按步骤优化并验证
先选出命中率低且回源量明显的路径，区分静态图片、播放清单、媒体分片和带权限内容，不要一次改全站。
核对响应头、查询参数、Cookie 和请求方法，确认哪些因素会改变返回内容；把实际影响内容的因素保留在缓存键中。
按内容更新方式分组设定 TTL。不可变分片可采用较长时长；频繁变化的清单应更短，并结合发布或刷新流程。
先对小范围路径或测试对象发布规则，分别验证首次请求、重复请求、内容更新、权限变化和 Range 播放；同时检查响应内容与缓存状态。
观察一段覆盖正常访问和内容更新的时间，再比较回源请求、命中率、错误率与用户侧播放或图片加载情况。发现串内容、旧内容或错误缓存时，立即回滚并清理受影响对象。
因此，图片和视频分发的缓存命中率优化方法不是单纯提高 TTL，而是让缓存键准确区分内容、让有效期匹配更新节奏，并验证异常状态与分段请求。命中率提升只有在内容正确、权限边界不变时才有意义。
常见问题
命中率越高越好吗？
不一定。缓存了错误版本或个性化内容，命中率再高也会造成问题；应同时看正确性、回源量和错误情况。
图片参数都应放进缓存键吗？
不必。只保留会改变响应内容或访问权限的参数；确认无影响的追踪参数可评估是否排除。
直播清单能设置很长缓存吗？
通常不适合。清单会随直播进度变化，较长缓存可能延迟播放进度；具体时长应结合更新频率和平台刷新能力验证。
规则改完后多久看结果？
至少覆盖一次典型内容更新周期，并结合访问量判断；低流量路径需要更长观察时间，不能只凭短时命中率下结论。
