优先选 lru；因为 functools.lru_cache 开箱即用、性能优、线程安全，而 lfu 无标准实现、手写易错、开销大，仅在明确存在高频固定 key 时才可能有优势。
LRU 和 LFU 在 Python 里到底用哪个？functools.lru_cache 是开箱即用的，functools.cache（Python 3.9+）是它的无限制版；而 LFU 没有标准库实现，得自己写或靠第三方。选谁不看“听起来更高级”，只看访问模式：如果最近用过的大概率还会再用（比如解析同一段配置、反复查用户 session），LRU 更稳；如果某些冷门但关键的条目被查得特别勤（比如全局配置里的 DEFAULT_TIMEOUT），LFU 才可能显优势。
为什么 lru_cache 不支持 LFU？
标准库的设计取舍很实在：lru_cache 底层靠双向链表 + 字典维护访问时序，O(1) 增删改；LFU 要统计频次 + 处理频次相同时的时序，至少得两层哈希（频次 → 条目集合，条目 → 频次），还要在频次提升时迁移节点——复杂度高、内存开销大，且多数业务场景压根不需要。Python 宁愿让你显式引入 heapq 或 collections.Counter 自搭，也不塞进标准库背锅。
手动实现 LFU 缓存容易踩哪些坑？
- get 和 put 都要更新频次，但频次相同时必须按最近使用时间淘汰，否则会误删刚查过一次的热 key
- 频次桶（bucket）用 defaultdict(list) 看似方便，但删除最低频次桶时，得确保该桶非空——漏判会导致 KeyError 或缓存击穿
- 没做容量上限检查：插入新项前不先 pop 最老的最低频项，缓存会无限膨胀
- 忘记把 get 触发的频次更新同步到时序结构里，导致后续淘汰逻辑错乱
lru_cache 不支持 LFU？
标准库的设计取舍很实在：lru_cache 底层靠双向链表 + 字典维护访问时序，O(1) 增删改；LFU 要统计频次 + 处理频次相同时的时序，至少得两层哈希（频次 → 条目集合，条目 → 频次），还要在频次提升时迁移节点——复杂度高、内存开销大，且多数业务场景压根不需要。Python 宁愿让你显式引入 heapq 或 collections.Counter 自搭，也不塞进标准库背锅。
手动实现 LFU 缓存容易踩哪些坑？
- get 和 put 都要更新频次，但频次相同时必须按最近使用时间淘汰，否则会误删刚查过一次的热 key
- 频次桶（bucket）用 defaultdict(list) 看似方便，但删除最低频次桶时，得确保该桶非空——漏判会导致 KeyError 或缓存击穿
- 没做容量上限检查：插入新项前不先 pop 最老的最低频项，缓存会无限膨胀
- 忘记把 get 触发的频次更新同步到时序结构里，导致后续淘汰逻辑错乱
示例片段（简化版核心逻辑）：
# 频次映射：freq → OrderedDict(key → value)
self.freq_to_items = defaultdict(OrderedDict)
# key → (value, freq)
self.key_to_val_freq = {}
self.min_freq = 0
性能和兼容性差异真有那么大？
- lru_cache 在命中率 > 80% 时，平均耗时通常在 20–50ns；手写 LFU 即使优化过，也常在 100–300ns，因为多层哈希查找 + 频次桶跳转
- Python 3.8 以下没 cache，也没 typing.ParamSpec，想给带泛型的函数加 LFU 装饰器，类型提示会断掉
- 多线程下，lru_cache 默认线程安全（靠内部锁），但手写 LFU 若只用 threading.Lock 包住整个 get/put，吞吐会暴跌；细粒度锁又容易死锁
事情说清了就结束。LFU 的理论优势，在真实 Python 服务中往往被实现成本、调试难度和微弱的命中率提升抵消。除非你有明确 trace 数据证明某几个 key 的访问频次远超其余且稳定，否则别碰它。
