事情本身不复杂，线索都在日志里。月报里缓存命中率 18%，比上月 60% 掉了 42 个百分点，可账单上的缓存节省金额基本没变。查下来是本月接入了批量任务，batch 请求本身不支持缓存，却全被算进了分母。把 batch 请求过滤掉之后，脚本又漏掉了带 background 参数的请求。
第一反应是「统计脚本按接口路径过滤，新接口没加进白名单」，验证下来不成立。
排查方向其实有限，先把可能性排一排。batch 与 background 请求不走缓存，算进分母必然拉低。还有一种是分母按请求条数算，批量任务一次提交上千条。
不容易想到的是，离线补算任务用同一套 key，被误计入在线流量。
先按接口路径拆分统计
python -c "import json,collections;c=collections.Counter(json.loads(l)['path'] for l in open('acc.jsonl'));print(c.most_common(5))"接着把不支持缓存的路径排除后再算
python -c "import json;rows=[json.loads(l) for l in open('acc.jsonl') if '/batch' not in l and 'background' not in l];print(len(rows))"给批量任务单独出一张表
python -c "print('batch rows counted separately')"剩下的就是把口径写进月报脚注
python -c "print('exclude batch and background')"怎么算真的好了，看的是同一批现象。在线请求的命中率回到 57%，趋势与账单里的缓存节省金额一致，批量任务单独列在另一张表里。
命中率的分母只该放支持缓存的那部分请求，接口一多就容易漏，白名单要跟着接口发布流程一起维护。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。