普通dict不做自动淘汰，高频写入时缓存持续膨胀致OOM；OrderedDict通过move_to_end()和popitem(last=False)实现O(1)LRU淘汰，兼顾顺序与高效修剪。
为什么直接用 dict 做缓存会爆内存？
因为普通 dict 不会自动丢弃旧项，哪怕只用一次的键也永远占着内存。尤其在高频写入、键空间不可控（比如用户 ID、URL 参数）的场景下，缓存会持续膨胀，最终 OOM。这不是设计缺陷，而是 dict 本就不该承担淘汰策略。
用 collections.OrderedDict 实现 LRU 自动修剪
它天然维护插入顺序，配合 move_to_end() 和 popitem(last=False) 就能低成本实现 LRU（最近最少使用）淘汰。关键不是“有序”，而是它支持 O(1) 的头部弹出和尾部更新。
- 每次
__getitem__或__setitem__后调用move_to_end(key)，把刚访问/写入的项移到末尾 - 写入前检查长度，超限时调用
popitem(last=False)弹出最老项（开头） - 不要用
list(od.keys())[0]找最老键——那是 O(n)，直接popitem才是 O(1)
from collections import OrderedDict
<p>class LRUDict:
def <strong>init</strong>(self, maxsize=128):
self._data = OrderedDict()
self.maxsize = maxsize</p><pre class="brush:php;toolbar:false;">def __getitem__(self, key):
value = self._data[key]
self._data.move_to_end(key) # 提升热度
return value
def __setitem__(self, key, value):
if key in self._data:
self._data.move_to_end(key)
elif len(self._data) >= self.maxsize > 0:
self._data.popitem(last=False) # 淘汰最老
self._data[key] = value
functools.lru_cache 能不能直接拿来当字典用？
不能。它是装饰器，绑定在函数上，缓存的是「函数调用结果」，不是任意键值对。你想存 {'user_123': {...}} 这种结构，它根本不提供 __setitem__ 或遍历接口。强行绕过（比如用单参数函数包装字典操作）会破坏语义，且无法手动清理或观察内部状态。
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
- 适用场景：纯函数计算结果缓存（如解析 JSON、查表转换）
- 不适用场景：需要主动增删改查、按需预热、监控命中率的业务缓存
- 它的淘汰是透明的，你无法捕获“某条被踢出”事件，调试和观测困难
线程安全与更复杂的淘汰策略怎么办？
OrderedDict 本身不是线程安全的。如果多线程并发读写，必须加锁——但别用全局 threading.Lock() 粗暴包裹所有方法，那会严重拖慢读性能。更合理的是读用 RLock，写操作才独占，或者直接用 threading.RLock 包裹写路径。
至于 LFU（最少使用）、TTL（过期时间），OrderedDict 就不够用了。这时候该上 lru-dict（C 扩展，支持 LFU）、cacheout（纯 Python，支持 TTL + 多策略），或者干脆用 Redis。自己手写带计数器+堆的 LFU 容易出错，且 Python 的 GIL 会让堆操作反而变慢。
真正容易被忽略的点是：缓存大小阈值不是越大越好。设成 10000 项，可能每项平均 2KB，就吃掉 20MB 内存；而实际热点往往集中在前 5% 键里。先用 collections.Counter 采样真实访问频次，再定 maxsize，比拍脑袋设值靠谱得多。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
