缓存异常不一定是缓存规则本身出错。做CDN日志分析定位缓存异常时，日志采集、字段含义和请求归并方式都可能让正常流量看起来异常，或掩盖真正的问题。下面五项风险值得先检查。
一、日志缺失或采样造成“流量断层”
部分平台会延迟交付日志，某些配置也可能启用采样；边缘节点产生的记录还可能因传输或解析失败而缺失。若只按源站日志统计请求量，缓存直接响应的请求本就不会全部出现在源站侧，不能据此断定边缘日志丢失。
核对同一时间段的边缘请求数、源站请求数和日志文件覆盖情况，确认统计口径一致；同时检查日志采样配置、交付延迟及采集管道报错。重点看异常是否集中在某个时间段或少数边缘节点。
二、时间戳与时区不一致
日志中的请求发生时间、写入时间和送达时间可能不是同一概念。边缘日志按 UTC 记录、分析平台按本地时区展示，或日志延迟到达，都可能造成“缓存异常早于配置变更”等误判。
分析前先确认时间字段定义和时区，再按事件发生时间排序。对照发布、缓存刷新和规则调整的记录时，统一时区，并为日志延迟预留观察窗口。不要把文件到达时间直接当作请求发生时间。
三、把缓存状态与 HTTP 状态混为一谈
响应码 200 只说明 HTTP 请求获得成功响应，不足以证明内容来自缓存。缓存状态字段则可能区分直接提供、回源获取、绕过缓存、重新验证或使用过期内容；具体名称和含义会因服务商、日志版本而不同。
这是CDN日志分析定位缓存异常时最常见的解释风险之一。先查对应平台的字段说明，再把缓存结果、边缘响应码和源站状态分列统计。若边缘返回 200、源站状态为空，可能是未回源；但仍需结合缓存状态和请求类型判断，不能仅凭空值下结论。
四、聚合时忽略缓存键差异
看似相同的请求，可能因查询参数、Accept-Language、Accept-Encoding、Authorization，或响应中的 Vary 规则而对应不同缓存对象。若报表只按路径汇总，某一种语言版本或压缩格式的缓存问题就可能被平均值掩盖。
排查时保留影响缓存键的字段，先比较异常请求与正常请求的差异，再检查规则是否预期将这些请求分开。注意不要在共享报表中暴露敏感请求头；可先脱敏或只保留是否存在、取值类别等必要信息。
五、重定向、重试和部分响应改变了请求形态
一次用户操作可能产生多条记录：客户端跟随重定向、边缘重试回源，或使用 Range 请求获取文件片段，都可能让日志中出现不同状态码或多次请求。条件请求还可能获得 304；它表示资源未变化，并不等同于普通的完整内容响应。
把这些记录误合并，可能误判缓存命中率或重复计算请求。分析时按请求追踪标识、目标资源、请求方法和时间关联记录；区分 301/302 跳转、206 部分响应、304 验证结果及重试记录，并确认平台是否将各环节分别记日志。
按这个顺序复核日志
选定异常时间窗和一条可复现的请求，记录请求方法、目标资源及必要的缓存键维度。
确认日志覆盖范围、采样设置、时间字段及时区，排除延迟到达和采集缺口。
按平台字段定义拆分缓存状态、边缘响应码与源站状态，不以单一状态码代替缓存结论。
检查重定向、重试、Range 和条件请求，再与缓存规则变更、刷新操作的时间线对照。
可靠的CDN日志分析定位缓存异常，关键是先确认日志是否完整、字段是否可比，再解释缓存行为。只有时间、请求形态和缓存键口径一致，统计结果才适合用于判断问题范围。
常见问题
为什么边缘请求数和源站请求数对不上？
缓存直接响应不会对应一次源站请求；此外，采样、重试、日志延迟和统计范围也会造成差异，应先核对口径。
响应码 200 能证明缓存正常吗？
不能。它说明 HTTP 响应成功，需结合缓存状态字段及源站状态判断内容是否由缓存提供。
排查时可以直接按资源路径汇总吗？
初步定位可以，但若查询参数、请求头或 Vary 规则影响缓存键，应保留相关维度继续拆分分析。
日志暂时没有记录是否代表请求没有发生？
不一定。检查日志交付延迟、采样和采集错误，并与其他观测数据交叉核对后再判断。
