直接用 functools.lru_cache 最简单高效，但仅适用于纯函数；自定义缓存需避坑：list/dict 手写 LRU 易致 O(n) 性能瓶颈，OrderedDict 非线程安全，高并发应手写双链表+分段锁，复杂需求宜选 Redis 等专业库。
直接用 functools.lru_cache 装饰器是最简单、最不容易出错的高性能方案，但仅适用于纯函数场景；若需自定义缓存行为（如带 TTL、线程安全写入、监控指标或非哈希参数），就得自己实现，且必须避开 OrderedDict 的隐式线程不安全和 list 的 O(n) 查找陷阱。
为什么不能直接用 list 或 dict 手写 LRU？
常见错误是用普通 list 存键顺序 + dict 存值：每次 get 都要 list.index(key)，时间复杂度变成 O(n)，缓存越大越卡；而单纯用 dict 无法维护访问顺序，淘汰逻辑只能靠遍历找“最老”项，同样 O(n)。Python 3.7+ 虽保证 dict 插入有序，但它不提供 move_to_end 或 popitem(last=False) 这类原子操作，手动重排会破坏一致性。
无序列表呈现：
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
-
list.index()和list.remove()在大数据量下极易成为性能瓶颈 - 多线程环境下，
dict+list组合没有内置锁，get和put并发时可能丢数据或抛KeyError - 即使加了
threading.Lock，锁粒度粗（整个缓存一把锁）会严重限制吞吐
OrderedDict 实现的坑比你想象的多
OrderedDict 确实封装了顺序管理，但它的 move_to_end 和 popitem 是 O(1)，这点没问题；问题在于它本身不是线程安全的——文档明确写 “not thread-safe”。如果你在 Web 服务里多个协程/线程共用一个 LRUCache 实例，不加锁就调 get/put，极大概率触发 RuntimeError: dictionary changed size during iteration 或静默数据错乱。
立即学习“Python免费学习笔记（深入）”；
无序列表呈现：
- 必须显式加
threading.RLock（推荐可重入锁，避免递归调用死锁） -
move_to_end(key)前必须先检查key in od，否则KeyError会中断流程 -
popitem(last=False)淘汰的是“最先插入”的项，不是“最久未访问”的项——除非你严格保证所有访问都走move_to_end，否则顺序会错乱
真正高性能的自定义实现：双链表 + weakref + 分段锁
当并发量高、缓存条目超万、且需要精确控制淘汰逻辑时，手写双链表仍是唯一可靠路径。核心不是“炫技”，而是规避 Python 对象引用和锁竞争带来的开销。关键点：
无序列表呈现：
- 节点类用
__slots__ = ('key', 'value', 'prev', 'next')省内存、提访问速度 - 哈希表（
dict）只存key → ListNode映射，避免重复查找 - 淘汰时用
weakref.ref包裹节点，防止循环引用阻碍 GC - 把大锁拆成“读锁 + 写锁”或按 key hash 分段（如 64 段），大幅降低争用
- 不要在
get中做任何 I/O 或耗时操作（比如日志打点），否则锁住整个链表
什么时候该放弃手写，转用专业缓存库？
一旦你的需求出现以下任意一条，就该停下手写，切到 redis、diskcache 或 aiocache：
无序列表呈现：
- 需要跨进程共享缓存（
lru_cache和单实例OrderedDict都做不到） - 要求 TTL（过期时间），而
lru_cache只支持容量淘汰 - 缓存项体积大（>1MB），频繁序列化/反序列化已成瓶颈
- 要监控实时命中率、淘汰率、平均延迟等指标，且需对接 Prometheus
- 部署在 Kubernetes 中，Pod 重启后希望缓存不全丢
最后提醒一句：lru_cache(maxsize=None) 看似省心，但若函数参数含 list 或 dict，会直接报 TypeError: unhashable type；而用 typed=True 后，f(1) 和 f(1.0) 就算两个缓存项——这些细节不验证 cache_info()，上线后根本发现不了。
