报错是这么冒出来的。提示词 system 段开头拼了「今天是 2026-11-11」，接的是 OpenAI 的上下文缓存，命中率从 78% 掉到 6%，账单里 cached token 几乎归零，把日期挪到用户消息里之后命中率又回来了。
中间走过弯路，把「多个实例各自注入时间，时区不同导致前缀不一致」当成主因，改完现象没变。
排查方向其实有限，先把可能性排一排。缓存按前缀逐 token 比对，system 首句一变整段前缀全部失效。还有一种是只精确到天的日期也足以让跨零点的请求全部落空。
少数情况下是既拼了日期又拼了请求 id，等于每个请求都是新前缀。
第一件事是打印实际发送的 system 前 200 字
python -c "print(open('system.txt',encoding='utf-8').read()[:200])"接着把易变字段移到消息尾部再对比
python -c "print({'system_head':'固定角色与规则','volatile':'date at tail'})"然后换一个固定前缀做一次请求看 cached 字段
curl -s https://api.openai.com/v1/chat/completions -H "Authorization: Bearer $OPENAI_API_KEY" -H 'Content-Type: application/json' -d '{"model":"gpt-4o-mini","messages":[{"role":"system","content":"你是客服助手 只回答售后问题"},{"role":"user","content":"今天是2026-11-11 退款要几天"}]}' | jq '.usage.prompt_tokens_details'等前面都确认过，再按天统计缓存命中率验证改动
python -c "print({'date':'2026-11-11','cached_ratio':0.06})"别只看报错消失，验证要多做一步。稳定前缀的请求 cached_tokens 明显大于零，命中率回到七成以上，跨零点后的第一批请求只影响少数调用。
容易忽略的是，缓存只认前缀，越稳定的内容越要放前面，日期、请求号这类每次都变的东西一律挪到后面或单独成条。报错文案容易误导，真正的原因往往在相邻那一层的日志里。