必须显式设置lru_cache的maxsize参数，否则缓存无限增长导致内存耗尽；@cache是无界且不可控的别名，类方法使用会阻止实例回收，含动态参数则缓存失效。
缓存没设上限，lru_cache 会吃光内存
Python 的 @lru_cache 默认不限制缓存条目数，一旦函数被高频调用且参数组合多（比如带用户 ID、时间戳、分页偏移），缓存表会无限膨胀，最终触发 MemoryError 或拖慢整个进程。
常见错误现象：服务运行几小时后 RSS 内存持续上涨，GC 频率升高，但 CPU 并不高；用 tracemalloc 能定位到大量 functools._lru_cache_wrapper 占用堆内存。
- 必须显式传
maxsize，例如@lru_cache(maxsize=128)，不写等于maxsize=None（无限制） - 数值不是越大越好——
maxsize=1024对高并发小对象还行，但若每个缓存项含大字典或 Pandas DataFrame，实际内存开销可能远超预期 - 注意
maxsize是按「调用签名」计数的，相同参数多次调用只占 1 个 slot；但list、dict等可变类型不能直接作参数（会报TypeError: unhashable type）
functools.cache 和 lru_cache 别混用
@cache 是 Python 3.9+ 新增的无界缓存装饰器，本质是 @lru_cache(maxsize=None) 的别名。它比 lru_cache 少了淘汰策略，纯靠引用计数 + GC 回收，不可控性更强。
使用场景：仅适合参数极少、结果极稳定、生命周期与程序一致的纯计算函数（比如解析固定配置文件的函数）。绝不能用于 Web 请求处理、数据库查询封装等动态场景。
立即学习“Python免费学习笔记（深入）”；
- 误把
@cache当轻量版@lru_cache用，等于主动放弃缓存管理权 - Python 3.8 及更早版本不支持
@cache，用了会直接NameError: name 'cache' is not defined - 两者缓存数据结构不共享，混用同一函数会导致两套缓存并存，内存翻倍且逻辑混乱
类方法加 @lru_cache 会泄漏实例
给实例方法加 @lru_cache 时，缓存键会包含 self 引用，导致整个实例无法被垃圾回收——哪怕外部已无其他引用，该实例仍驻留内存。
典型表现：创建大量短生命周期对象（如 Flask request context、临时 DTO），缓存后观察 gc.get_objects() 发现旧实例持续堆积。
- 解决方案一：改用静态方法或模块级函数，把
self相关状态抽成参数传入 - 解决方案二：用
@lru_cache修饰@staticmethod，但需确保所有参数可哈希 - 绝对不要对
@property加@lru_cache——除非你明确知道这个属性值永不变，且所属实例会长期存活
缓存键包含时间或随机值就等于没缓存
如果函数参数里有 datetime.now()、time.time()、random.random() 或 UUID，每次调用缓存键都不同，lru_cache 彻底失效，还白占内存和哈希计算开销。
这种写法常出现在“带过期逻辑”的伪缓存中，比如手动拼接时间戳进参数试图控制刷新——实际只是让缓存变成单次有效。
- 正确做法：缓存本身不负责过期，用
functools.lru_cache+ 外部定时清理，或换用cacheout、redis等支持 TTL 的方案 - 调试技巧：在被装饰函数开头加
print(f"Cache key: {args!r} {kwargs!r}")，快速验证键是否稳定 - 注意
float参数可能因精度问题导致键不一致，优先转成int或字符串再传入
