functools.lru_cache不用手写双向链表，因其底层由C实现哈希表+双向链表，性能高、线程安全、自动处理参数哈希与类型感知，而手动用OrderedDict易出错且慢。
为什么 functools.lru_cache 不用自己写双向链表
因为 Python 标准库的 lru_cache 已经用 C 实现了高效淘汰逻辑，底层确实是哈希表 + 双向链表（但封装在 C 层），你手动用 OrderedDict 模拟反而慢、易错、且不兼容多线程。
常见错误现象：OrderedDict.move_to_end(key) 在高并发下抛 KeyError，或缓存命中率远低于预期——根本原因是没处理好并发读写和键访问时序。
-
lru_cache自动处理调用参数的哈希与相等性（支持不可变嵌套结构），OrderedDict手动管理只认对象身份（id()），字典键一变就失效 - Python 3.9+ 的
lru_cache支持typed=True，能区分1和1.0；手写方案几乎没人做这层类型感知 - 性能上，C 实现的
lru_cache查找是 O(1)，而OrderedDict的move_to_end虽然均摊 O(1)，但每次调用都有 Python 层开销，压测下差距明显
lru_cache 的 maxsize 参数到底怎么设才不踩坑
设成 None 看似“无限缓存”，实际会持续增长直到内存耗尽；设成 128（默认值）又可能对高频小数据函数造成频繁驱逐。
使用场景：比如一个解析 JSON 字符串的函数，输入固定、重复率高，但单次结果几 MB —— 这时缓存 10 个就可能吃光几百 MB 内存。
- 先用
cache_info()观察真实命中率：my_func.cache_info().hits / (my_func.cache_info().hits + my_func.cache_info().misses) - 如果
currsize接近maxsize且misses持续上升，说明该扩容；如果hits极低，直接关缓存更省事 - 避免用变量动态传
maxsize：@lru_cache(maxsize=MAX_CACHE_SIZE)中的MAX_CACHE_SIZE必须是常量，否则装饰器在定义时就报错
带参数的函数怎么缓存：lru_cache 不支持 kwargs 吗
它原生只对位置参数和关键字参数的**组合签名**做哈希，但要求所有参数都可哈希。一旦出现 dict、list、set 这类不可哈希类型，直接抛 TypeError: unhashable type。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
常见错误现象：函数接收一个 config: dict 参数，本地测试正常，上线后因 config 字段顺序不同导致缓存未命中——本质是 dict 本身不可哈希，装饰器连哈希都不让算。
- 解决方案不是改用
OrderedDict，而是预处理：把dict转成frozenset(config.items())或tuple(sorted(config.items())) - 更稳妥的做法是拆出真正影响结果的字段，作为独立参数传入，其余丢进
**kwargs并不参与缓存（lru_cache默认忽略未出现在签名里的参数） - 别试图给
lru_cache加一层 wrapper 去序列化参数：JSON 序列化慢、浮点精度丢失、无法处理自定义对象
为什么不能用 lru_cache 缓存实例方法
因为默认会把 self 对象整个塞进缓存键，而大多数实例对象不可哈希，或者即使可哈希（如 dataclass 且 frozen），不同实例哪怕状态相同也被视为不同键。
使用场景：比如一个 Document.parse() 方法，想按文档内容缓存解析结果——但 self 是实例，内容在 self.text 里。
- 正确做法是把逻辑抽成模块级函数：
def parse_document(text: str) -> AST:，再对其加@lru_cache - 如果非要用方法，可用
functools.cached_property（Python 3.8+），但它只缓存一次、不支持 LRU 淘汰，也不接受参数 - 强行用
lru_cache装饰实例方法，会导致每个实例都有一份独立缓存，内存泄漏风险极高，且无法跨实例复用
最常被忽略的一点：缓存键的计算发生在函数调用前，但如果你在函数体内修改了可变默认参数（比如 def f(x, cache=[])），那缓存行为会和预期完全脱节——这种 bug 不报错，只悄悄返回旧结果。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
