@lru_cache提升性能的关键在于合理配置参数与甄别适用函数：需满足纯函数、调用频繁、计算开销大、参数可哈希且范围有限；慎设maxsize，善用typed=true和cache_clear()，避免嵌套污染，必要时选用redis等专业缓存方案。
Python 的 @lru_cache 是提升重复计算函数性能的利器，但用不好反而拖慢程序、吃光内存。关键不在“加不加装饰器”，而在“怎么配参数”和“函数是否适合缓存”。
明确缓存适用场景：不是所有函数都值得缓存
缓存真正起效的前提是：函数纯（相同输入必得相同输出）、调用频繁、计算开销大、输入参数可哈希且取值范围有限。
- ✅ 适合：递归斐波那契、解析固定配置、查表型数值计算
- ❌ 不适合：含时间/随机数/全局状态的函数；参数是 list/dict/自定义对象（不可哈希）；返回结果巨大（如大数组）
- ⚠️ 注意：若参数含不可哈希类型（如
list），需先转成tuple或用functools._make_key自定义键生成逻辑
合理设置 maxsize：别让缓存变成内存黑洞
maxsize 默认为 128，看似安全，但实际中常需调整：
- 设为
None表示无限制——仅适用于输入组合极少且确定不会爆炸的场景（如枚举几十种固定 ID） - 设为
1适合“只记上一次结果”的场景（如轮询接口时缓存最近响应） - 对参数维度高或取值广的函数（如带浮点精度、字符串长度不定），建议显式设较小值（如
32或64），并配合typed=True避免 int/float 混用冲突
善用 typed 和手动清除机制
typed=True 让缓存区分 1 和 1.0，避免类型隐式转换导致命中失败，尤其在科学计算或 API 参数校验中很实用。
立即学习“Python免费学习笔记（深入）”；
- 手动清空缓存：
func.cache_clear()—— 适合配置变更、数据刷新后重置 - 查看缓存状态：
func.cache_info()返回CacheInfo(hits, misses, maxsize, currsize)，上线前务必打印验证是否真有命中 - 避免装饰器嵌套污染：若函数已用其他装饰器（如
@wraps），确保@lru_cache在最内层，否则可能缓存包装后的闭包而非原函数
替代方案：轻量级缓存 + 显式控制
当 @lru_cache 灵活性不足（如需 TTL、异步失效、多级缓存），可用更底层方式：
- 用
functools.lru_cache(maxsize=...)返回的 cache 对象做细粒度操作 - 结合
dict+time.time()实现带过期的简易缓存（适合单次脚本） - 对 Web 服务等长期运行进程，优先考虑 Redis 或
dogpile.cache这类专业库
