线上python服务异常时，应优先排查@cache装饰器导致的缓存不一致问题：检查是否使用@cache、参数是否可变或未重写__hash__、本地与线上执行环境差异，并通过禁用缓存、清空缓存或打印cache_info快速验证；修复需确保参数不可变、避免缓存依赖外部状态的函数，必要时改用带TTL的缓存方案，并预留运行时调试接口和监控指标。
线上 Python 服务出问题，别急着改代码、重启或查日志大海捞针。核心是：快速定位「哪段逻辑没按预期执行」，而 @cache（来自 functools）恰恰是个高频“隐形炸弹”——它让函数结果被缓存，但缓存不感知外部状态变化，极易导致线上行为和本地调试不一致。
先确认是不是 @cache 搞的鬼
很多线上 bug 表现为“数据明明更新了，接口返回还是旧的”，尤其在配置、数据库查询、时间敏感计算等场景。这不是逻辑错，是缓存没失效。
- 检查目标函数是否加了
@lru_cache()、@cache或自定义缓存装饰器 - 看调用参数是否“看似相同实则不同”：比如传了可变对象（list/dict）、未重写
__hash__的自定义类、或用了datetime但精度到秒而实际需要毫秒 - 本地复现时，可能因单次运行、无并发、参数固定，缓存没暴露问题；线上多请求+参数微变+缓存命中，就卡在旧结果里
临时绕过缓存，验证猜想
不改业务逻辑，快速验证是否缓存导致异常：
- 在出问题的函数上加个临时开关，比如读环境变量：
if os.getenv("DISABLE_CACHE"): return func(*args, **kwargs) - 用
func.cache_clear()在关键路径前手动清空（适合低频触发点） - 在日志里打一行：
logger.info(f"Cache info: {func.cache_info()}")，看命中率、最大大小、当前条目数——如果hits高但结果错误，基本坐实
安全替换或加固 @cache
不是所有地方都不能缓存，而是得让它“缓得明白”：
立即学习“Python免费学习笔记（深入）”；
- 避免缓存带副作用或依赖外部状态的函数（如
get_user_config()应该主动监听变更，而非靠缓存） - 参数务必不可变：用
tuple替代list，用dataclasses.frozen=True或NamedTuple包装复杂参数 - 需要时效性？不用
@cache，改用带 TTL 的方案，比如functools.lru_cache(maxsize=128, typed=False)不够用，换成dogpile.cache或redis+ 过期时间 - 调试阶段可在装饰器里加日志：
@lru_cache(...); def f(...): logger.debug(f"Cache miss for {args}")，上线前删掉
线上调试要留“后门”
别等出事才翻代码。提前埋点能让问题收敛速度提升一个量级：