Python字典本身不支持LRU淘汰，需用OrderedDict实现：通过move_to_end()置顶访问项、popitem(last=False)删除最老项，确保“最近读取优先”；@lru_cache仅适用于可哈希参数且按数量限容的场景。
Python字典本身不支持LRU淘汰，但可以配合OrderedDict实现
字典（dict）在 Python 3.7+ 虽然保持插入顺序，但它没有内置的“最近最少使用”访问标记能力。想靠纯 dict 实现 LRU 缓存，必须手动维护访问顺序——这容易出错，也不高效。
真正靠谱的做法是用 collections.OrderedDict：它的 move_to_end() 和 popitem(last=False) 天然适配 LRU 的“查则置顶、满则删底”逻辑。
-
OrderedDict在 Python 3.7+ 中性能已接近普通dict，不必担心明显开销 - 别用
dict.keys()或list(dict)来模拟顺序——它们不反映访问历史，只反映插入顺序 - 如果用
@lru_cache，它底层其实也是基于OrderedDict，但封装太深，自定义淘汰策略（比如按大小而非数量限制）时反而更难控制
手动实现LRU缓存时，__getitem__和__setitem__必须协同更新顺序
很多初学者只重写 __setitem__，忘了在读取时也要把对应 key 移到末尾——结果缓存行为变成“最近写入优先”，而不是“最近读取优先”，完全违背 LRU 本意。
正确做法是：每次 __getitem__ 成功后调用 self.move_to_end(key)；每次 __setitem__ 前检查容量，超限时用 self.popitem(last=False) 删最老项。
立即学习“Python免费学习笔记（深入）”；
- 注意：
move_to_end(key, last=True)是默认行为（移到末尾），表示“刚被访问”，别写成last=False - 如果 key 不存在却调用了
__getitem__，会触发KeyError，这时不能调用move_to_end——得先捕获异常再处理 - 并发场景下，这个手动实现不是线程安全的；需要加
threading.Lock，但锁粒度太大可能拖慢性能
@lru_cache够用吗？看这三个限制是否踩中你的需求
@lru_cache 是最省事的选择，但它有硬性约束：只能缓存函数的返回值，且参数必须可哈希。一旦遇到以下情况，就得自己动手：
- 缓存对象生命周期需主动控制（比如某个值过期了要手动
cache_clear()，但又不想清空全部） - 键是不可哈希类型，比如
dict或list—— 此时必须预处理成字符串或元组，而@lru_cache不提供钩子 - 想按内存占用（如总字节数）而非条目数限容——
maxsize只认数量，不管每个值多大
示例：你想缓存一个大 JSON 响应，但总内存不能超 10MB。这时候 @lru_cache(maxsize=128) 完全没用，得自己在 __setitem__ 里算 sys.getsizeof(value) 并动态调整。
用dict + 时间戳模拟LRU？别这么做
有人试图给每个 key 配一个 last_accessed 时间戳，查缓存时遍历全量找最小时间戳来淘汰——这在数据量稍大（比如 >1000 条）时就会明显变慢，且无法保证原子性。
根本问题在于：字典没有 O(1) 获取“最旧项”的能力，而 OrderedDict.popitem(last=False) 是真 O(1)。
- 时间戳方案还面临浮点精度、时钟回拨、多线程写冲突等问题
- 即使加了
heapq维护时间堆，也会引入额外空间和同步成本，得不偿失 - 如果你只是想“定期清理过期项”，那应该用带 TTL 的缓存库（如
redis或diskcache），而不是在本地字典里硬加时间逻辑
str(args) + str(kwargs) 当 key，遇到浮点数精度、字典顺序差异、或含不可序列化对象时，会悄悄导致缓存击穿或重复计算——这事不会报错，只会让你花半天怀疑逻辑。 
