这个坑值得记一笔。灰度开关接的是 OpenFeature 的 Python SDK，默认六十秒客户端缓存，晚上九点把新模型开关关掉，日志里仍有约两成请求走 gpt-4.1 而不是 gpt-4.1-mini，持续了将近一分钟才全部切回；中间重启过其中一个 Pod，那个 Pod 立刻恢复正常。
刚开始盯着「开关读的是本地兜底值，服务端变更没有推送下来」，折腾了半个多小时，排掉了。
原因不止一个，得分开看。SDK 默认缓存六十秒，关开关不会立刻生效；每个 Pod 各自求值，缓存到期时间并不同步；后台任务在启动时取了一次值就常驻内存。
动手时先确认这个开关的求值来源和默认值
python -c "from openfeature import api;c=api.get_client();print(c.get_boolean_value('use_new_model',False))"带上下文连续求值三次看结果是否一致
python -c "from openfeature import api;c=api.get_client();print([c.get_boolean_value('use_new_model',False,{'targeting_key':'u1'}) for _ in range(3)])"随后确认服务端配置下发通道连通
curl -s http://flagd:8013/schema/v1/flag -H "Authorization: Bearer $TOKEN" | Select-Object -First 1等前面都确认过，再关掉开关后按 uid 抽样核对实际走的模型
python audit_route.py --since 21:00 --by uid --expect gpt-4.1-mini怎么算真的好了，看的是同一批现象。关闭开关后五秒内核验的五百个请求全部走 gpt-4.1-mini，各 Pod 的求值结果一致，日志里不再出现新旧模型混跑。
提醒一点。开关关不掉多数不是服务端没写成功，而是各客户端还在缓存里，灰度回滚必须把缓存刷新一起写进预案。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。