缓存未清理导致内存持续增长：@lru_cache或字典缓存若键空间失控，强引用会阻止gc回收，引发memoryerror；weakref.weakvaluedictionary可避免阻塞回收；typed=true易致键膨胀、命中率下降；实际内存占用取决于返回值大小而非缓存数量。
缓存没清掉，内存就一直涨
Python 的 @lru_cache 或手动字典缓存，一旦键空间不受控，内存占用会持续累积，且 GC 很难回收——因为缓存对象本身是强引用，只要缓存容器活着，里头的值就不会被释放。
常见错误现象：MemoryError 在长时间运行服务中突然出现；psutil.Process().memory_info().rss 显示内存稳步上升，但对象计数（len(gc.get_objects())）没明显变化——说明不是“新对象爆炸”，而是旧值被缓存钉住了。
- 使用场景：高频调用、参数组合多的纯函数（比如解析配置、查表转换），尤其在 Web 请求循环或数据管道中反复复用
- 参数差异：
@lru_cache(maxsize=128)比@lru_cache()（即maxsize=None）安全得多；但若实际调用键远超 128（比如时间戳毫秒级、UUID 类参数），仍等效于无限制 - 性能影响：
maxsize=0禁用缓存但保留装饰器开销；maxsize=None最快但最危险；中间值需按键的熵来估算，别拍脑袋设 1024
用 weakref 替代强引用缓存
当缓存项本身是大型对象（如 pandas.DataFrame、numpy.ndarray），又不希望它因被缓存而阻止回收，就得绕过强引用。标准库的 weakref.WeakValueDictionary 是更稳妥的选择。
它只保存对象的弱引用，一旦对象外部引用消失，缓存条目自动失效，不阻塞 GC。
立即学习“Python免费学习笔记（深入）”；
- 适用场景：缓存“结果对象”而非“计算结果值”，比如缓存某个文件路径对应的已加载模型实例
- 注意点：
WeakValueDictionary的键必须是不可变类型（str、int、tuple），值必须支持弱引用（大多数自定义类默认支持，但含__slots__且未显式声明__weakref__的不行） - 不能直接套用
@lru_cache：得自己封装逻辑，比如用functools.lru_cache缓存 key → id 映射，再用WeakValueDictionary存真实值
@lru_cache 的 typed=True 会悄悄翻倍内存
开启 typed=True 后，(1, 1.0) 和 (1.0, 1) 被视为不同键——表面上是类型安全，实际上让缓存键空间膨胀，尤其在混合数值类型（int/float）、泛型参数场景下。
实测：某配置解析函数开启 typed=True 后，缓存命中率从 72% 降到 19%，内存占用多出 3.2 倍（因重复缓存了本可合并的变体）。
- 除非你明确依赖
int和float的语义区分（比如单位校验），否则关掉它 - 检查方式：打印
func.cache_info()，对比hits/misses比例；若currsize接近maxsize但hits极低，大概率是键粒度太细 - 兼容性注意：CPython 3.8+ 才支持
typed参数；PyPy 行为略有差异，建议统一关掉以保一致
评估内存影响必须看实际键分布，不是看代码行数
写一个 @lru_cache(maxsize=512) 不代表最多占 512 个对象内存——每个缓存项的大小取决于返回值本身。一个返回 bytes(1024*1024) 的函数，满缓存就是 512MB；返回 int 就不到 10KB。
真正要做的，是采样真实调用流，统计键的唯一性、返回值大小分布，而不是靠“应该不会太多”来赌。
- 快速验证方法：在缓存函数内加钩子，用
sys.getsizeof(result)记录每次缓存项大小，定期输出 top N 大的键和尺寸 - 容易被忽略的点：字符串拼接、JSON 序列化结果、临时生成的
dict都可能隐式放大体积；__slots__类比普通类省内存，但缓存它时，实例本身大小 ≠ 缓存开销（因为还存了__dict__的引用） - 生产环境慎用
tracemalloc全局追踪——开销太大；优先用objgraph定向查缓存字典里的大对象引用链
