线路缓存不命中排查

本页说的是什么缓存？

本页讨论的是本站线路的响应缓存（全球加速-2、cf-2 提供的 1 小时缓存），不是模型提供商的 Prompt Cache。关于 Prompt Cache，请参阅 基础知识：Prompt Cache。

什么情况下缓存不会命中？

缓存 key 由 请求路径 + API Key + 整个请求体 三部分哈希计算。任何一部分有差异，缓存就不会命中。

排查步骤

1. 确认你使用的是缓存线路——只有「全球加速-2」和「cf-2」支持缓存，其他线路没有缓存功能
2. 确认缓存未过期——缓存 TTL 固定 1 小时，超过 1 小时后自动失效
3. 逐字比对请求体——整个 JSON body 参与哈希，任何字符差异都会导致不命中
4. 确认 API Key 一致——不同 Key 的缓存互相隔离
5. 确认请求路径一致——/v1/chat/completions 和 /upstream-stream/v1/chat/completions 是不同的路径

常见的"以为能命中但实际不能"的场景

stream 字段不同

第一次请求 "stream": true，第二次请求 "stream": false——请求体不同，不命中。

temperature 或其他参数不同

第一次 "temperature": 0.7，第二次没传（模型用默认值）——请求体不同，不命中。

消息内容有细微差异

messages 中多了一个空格、换行、或标点不同，都会导致哈希不一致。

客户端自动添加了额外字段

部分客户端会在请求体中自动添加 user、n、时间戳等字段。即使你看到的对话内容相同，实际发出的请求体可能每次都不一样。

如何确认实际请求体？

在主站「控制台 → 使用日志」中可以查看每次请求的详细信息。对比两次请求的完整内容，找出差异。