@lru_cache有时拖慢程序：因参数不可哈希报错、大返回值耗内存触发GC、隐式状态导致缓存过期错误；应先性能分析，确保参数不可变、限制maxsize，避免缓存I/O或随机函数。
为什么 @lru_cache 有时反而拖慢程序？
不是所有函数都适合加 @lru_cache。如果函数参数是不可哈希类型（比如 dict、list），会直接抛出 TypeError: unhashable type；如果返回值很大（如长字符串或嵌套结构），缓存本身会吃掉大量内存，甚至触发频繁 GC；更隐蔽的是，若函数有隐式状态（比如依赖全局变量、文件读取或时间戳），缓存会返回过期结果，导致逻辑错误。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 先用
timeit或cProfile确认该函数确实是性能瓶颈，且重复调用比例高 - 确保参数全为不可变类型：用
tuple替代list，用frozenset替代set - 显式限制大小：
@lru_cache(maxsize=128)，避免无限增长；设为None表示无上限，但生产环境慎用 - 对含 I/O 或随机性的函数，别缓存——改用显式状态管理或加版本号参数来“绕过”缓存
functools.cache 和 @lru_cache() 到底选哪个？
functools.cache 是 Python 3.9+ 引入的简写，等价于 @lru_cache(maxsize=None)，底层共享同一实现。区别只在语义和可控性：
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 需要控制缓存容量（防内存爆炸）→ 用
@lru_cache(maxsize=...) - 只是想快速启用无限制缓存，且确定参数轻量、调用稳定 → 用
@cache更简洁 - Python @cache，必须用
@lru_cache() - 两者都不支持线程安全的自动刷新；多线程下若需并发访问，得自己加
threading.RLock或改用cached_property
类方法怎么正确缓存？避开 self 导致的缓存失效
直接对实例方法加 @lru_cache 会失败，因为 self 是可变对象，无法哈希。常见错误写法：@lru_cache 放在 def method(self, x): 上 → 报 unhashable type: 'MyClass'。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 把逻辑抽成独立函数（不带
self），再缓存它，类内调用该函数 - 用
@cached_property缓存**属性级**结果（只计算一次，绑定到实例），适用于初始化开销大、后续只读的场景 - 若必须按实例+参数组合缓存，可手动构造 key：比如
@lru_cache装饰一个接收id(self), x的函数，但要注意id复用风险，不推荐用于长生命周期对象 - 对类方法（
@classmethod）可直接缓存，因cls是类型对象，可哈希
缓存键冲突：两个不同输入算出同一个 hash 怎么办？
@lru_cache 依赖参数的 __hash__ 和 __eq__。自定义类若没重写这两个方法，默认用 id，看似安全；但一旦重写了 __eq__ 却没同步更新 __hash__（比如设为 None），就会导致所有实例 hash 为 0，全部命中同一个缓存槽——结果错乱且难以排查。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 自定义类要进缓存，必须同时正确定义
__hash__和__eq__，且满足“相等对象必须有相同 hash” - 简单方案：用
@dataclass(frozen=True)，它自动生成兼容的__hash__和__eq__ - 调试时加日志：在被缓存函数开头打印
args和repr(args)，确认传入值是否真的一致 - 怀疑键冲突时，临时替换为
@lru_cache(maxsize=1)，看是否仍复用结果——若仍复用，大概率是 hash 冲突而非逻辑问题
