lru_cache真有效需满足三前提：函数纯、参数可哈希、调用存在重复；典型场景如斐波那契递归、固定JSON解析、静态枚举转换；参数含时间戳/UUID或函数有副作用时禁用，否则缓存无效反增开销。
lru_cache 能直接避免重复计算，但前提是函数必须是纯的、参数可哈希、且调用模式确实存在重复 —— 否则加了反而拖慢执行。
什么时候加 lru_cache 才真有效？
缓存只有在「相同参数反复出现」时才有价值。比如递归函数（如 fibonacci）、配置解析（如 json.loads 频繁解析同一段字符串）、或固定枚举值的转换逻辑。
- 参数几乎不重复（如带时间戳、UUID、随机数）→ 缓存命中率趋近于 0，每次还要多一次字典查找 + 哈希计算，纯 overhead
- 函数有副作用（如写文件、发请求、修改全局状态）→ 缓存后副作用只发生一次，后续调用“静默跳过”，结果不可控
- 返回值依赖外部状态（如读取未缓存的文件、数据库最新行）→ 缓存结果会 stale，且无自动失效机制
典型有效场景：expensive_parse(s) 解析固定 JSON 字符串；is_prime(n) 判断小整数是否为质数；get_user_role(user_id) 查角色映射表（数据静态或极少更新）。
maxsize 和 typed 怎么设才不踩坑？
这两个参数直接影响缓存行为和内存安全：
立即学习“Python免费学习笔记（深入）”；
-
maxsize=128（默认）适合多数场景：足够覆盖热点参数，又不至于吃光内存 -
maxsize=None表示无限缓存 → 仅适用于参数空间极小（如枚举值 ≤ 100 个）且生命周期短的函数；否则可能引发内存泄漏 -
typed=True会让1和1.0视为不同键 → 多数业务函数不需要，但涉及数值精度敏感场景（如金融计算）可启用 -
typed=False（默认）更宽松，但要注意int和float混用可能导致意外未命中
示例：
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
from functools import lru_cache <p>@lru_cache(maxsize=64, typed=True) def compute(x: float): return x *<em> 2 + x </em> 1.5</p><p>compute(2) # → miss（int） compute(2.0) # → miss（float），与上一条独立缓存</p>
怎么确认缓存真的起作用了？
别靠猜，用 cache_info() 看真实命中情况：
-
hits> 0 且持续增长 → 缓存生效 -
misses远大于hits→ 参数重复率低，考虑撤掉装饰器 -
currsize接近maxsize且不再增长 → LRU 淘汰已启动，缓存处于稳定态
实操建议：
- 上线前加一句
print(func.cache_info())观察几轮调用 - 在日志里定期输出（如每 1000 次调用一次），避免高频打印影响性能
- 注意：
cache_clear()会重置计数器，调试时慎用
缓存结果变了，函数却没重新执行？
lru_cache 不感知外部变化 —— 它只认参数，不认函数体或依赖数据。这是最常被忽略的点：
- 你改了函数内部逻辑，但没清缓存 → 老结果还在用
- 依赖的全局变量或配置变了 → 缓存不自动失效
- 数据源更新了（如查缓存前加载的字典）→ 缓存结果已过期，但无感知
应对方式很实际：
- 开发期：每次改函数逻辑后手动调用
func.cache_clear() - 运行期：对需要时效性的函数，不要用
lru_cache，改用带 TTL 的方案（如functools.cached_property+ 定时 reload，或第三方库cachetools.TTLCache） - 若必须用
lru_cache且需手动控制，把关键依赖项（如版本号、时间戳）显式作为函数参数传入，让缓存键自然失效
缓存不是银弹，它把「重复计算」换成「内存占用 + 键查找」，而这两者在参数不重复或函数不纯时，代价远高于收益。真正省下的时间，永远来自对调用模式的诚实观察，而不是盲目装饰。
