@lru_cache失效主因有四：一是参数不可哈希（如list/dict）导致缓存完全不启用；二是可变默认参数破坏键一致性；三是直接装饰实例方法因self不可哈希而无效；四是LRU容量淘汰或手动清空。
Python函数缓存（如 @lru_cache）失效，通常不是缓存“坏了”，而是调用方式或参数特性触发了缓存机制的限制条件。理解这些限制，才能避免误以为缓存没生效。
不可哈希参数导致缓存完全不启用
@lru_cache 要求所有位置参数和关键字参数都必须是可哈希的（hashable）。一旦传入 list、dict、set 或自定义的不可哈希对象，缓存会直接跳过，每次调用都重新执行函数，且不报错——这是最隐蔽的失效原因。
- 错误示例：
my_func([1, 2], key={'a': 1})→ 缓存不记录任何条目 -
解决方法：改用元组代替列表（
(1, 2)），用types.MappingProxyType(dict)或 frozenset 代替 dict/set；或在函数内部做标准化转换（如tuple(sorted(kwargs.items()))） - 验证技巧：调用后检查
my_func.cache_info()，若hits=0且currsize=0，大概率是参数不可哈希
默认参数变化引发意外缓存击穿
带默认值的参数（尤其是可变默认参数）容易造成逻辑混淆。例如：
from functools import lru_cache@lru_cache() def load_config(config_dict={}): # 危险！{} 是可变默认参数 return config_dict.copy()
第一次调用 load_config() 后，config_dict 实际指向同一个字典对象；后续修改该字典会影响缓存键的“内容一致性”，但缓存键仍基于初始 id 或引用，导致结果与预期不符。
立即学习“Python免费学习笔记（深入）”；
- 正确做法：默认值用
None，函数内初始化：config_dict = config_dict or {} - 更安全写法：
def load_config(config_dict=None): config_dict = {} if config_dict is None else config_dict
实例方法未绑定缓存装饰器
@lru_cache 不能直接用于实例方法（self 是不可哈希的），否则每次调用都会因 self 不同而生成新缓存项，形同未缓存。
- 现象：类中
@lru_cache的方法，即使参数相同，cache_info().currsize持续增长 - 方案一（推荐）：提取为独立函数，接收所需数据（非 self）作为参数，再缓存
- 方案二：使用
@lru_cache+@staticmethod，但需确保所有输入可哈希且不含实例状态 - 方案三：改用支持实例方法的第三方库，如
cached-property（适合属性级缓存）或methodtools
缓存容量/时间限制触发主动淘汰
@lru_cache(maxsize=N) 在达到容量上限时会按 LRU 策略清除旧项；而 maxsize=None 虽无数量限制，但内存占用可能随调用增长。此外，Python 进程重启、模块重载、或显式调用 cache_clear() 都会导致缓存清空。
- 调试建议：定期打印
func.cache_info()，关注maxsize、currsize和misses变化趋势 - 若需时效控制：不要依赖
lru_cache做过期管理，改用functools.cached_property（单次）、或结合time.time()自建带 TTL 的缓存封装 - 注意：多线程下
lru_cache是线程安全的，但高并发可能导致缓存项被频繁挤出，可适当增大maxsize或改用线程局部缓存
缓存不是银弹，而是需要匹配使用场景的工具。看清参数本质、避开实例绑定陷阱、合理设置容量边界，才能让 @lru_cache 真正发挥作用。
