手写缓存装饰器旨在理解lru_cache失效边界、参数可哈希要求及真实陷阱；需安全生成键（标准化kwargs为排序tuple、避免id/hash）、用哨兵对象判命中、并发用双重检查+锁、ttl简单实现但不内置lru。
手写缓存装饰器不是为了替代 @functools.lru_cache，而是为了理解它在什么边界下会失效、为什么参数必须可哈希、以及如何应对真实场景里的常见陷阱。
缓存键怎么生成才安全？
直接用 args 和 kwargs 的原始值做键，会遇到两类问题：不可哈希类型（如 dict、list）报 TypeError；浮点数精度或对象身份混淆导致重复计算。
- 推荐先标准化输入：把
kwargs转成按 key 排序的 tuple，args保持原样但要求所有元素可哈希 - 对不可哈希类型（如配置字典），应显式转成
json.dumps(conf, sort_keys=True)或tuple(sorted(conf.items())) - 避免用
id()或object.__hash__()——它们反映的是内存地址，不是逻辑等价性
为什么不能直接缓存返回值为 None 或 NaN？
很多手写实现用 cache_dict.get(key) is not None 判断命中，这会让 None、0、False、空字符串甚至 float('nan') 全部被误判为“未命中”。
- 正确做法是用哨兵对象，比如
_cache_missing = object()，然后查cache_dict.get(key, _cache_missing) is not _cache_missing - 如果函数本身可能返回
NaN，需额外用math.isnan()单独判断，不能依赖==或is
并发环境下缓存读写怎么不丢数据？
多个线程/协程同时调用同一函数，且缓存未命中时，若不做控制，会重复执行原函数并覆盖彼此结果。
立即学习“Python免费学习笔记（深入）”；
- 最轻量解法：用
threading.Lock包裹整个“查缓存 → 执行 → 写缓存”流程，但会串行化调用，影响吞吐 - 更优方案是“双重检查 + 锁”，即先查一次，没命中再加锁，再查一次（防止锁期间已被其他线程写入），再执行
- 异步场景下不能用
threading.Lock，得换asyncio.Lock，且注意装饰器本身要支持async def函数
缓存要不要支持过期和清理？
纯内存缓存默认永不过期，但实际中常需要 TTL 或按条件淘汰。手写时别硬塞复杂策略，优先满足明确需求：
- 简单 TTL：存值时附带
time.time()时间戳，每次读取前检查是否超时，超时则删键并重新计算 - 不建议在装饰器里内置 LRU 驱逐逻辑——那等于重造
lru_cache，容易出 bug；真有容量限制，直接用maxsize=128参数更可靠 - 清理接口要暴露出来，比如返回一个
clear()方法绑定到被装饰函数上，而不是藏在闭包里无法调用
def cache_with_ttl(ttl=60):
def decorator(func):
cache = {}
def wrapper(*args, **kwargs):
key = (args, tuple(sorted(kwargs.items())))
now = time.time()
if key in cache:
result, timestamp = cache[key]
if now - timestamp < ttl:
return result
else:
del cache[key]
result = func(*args, **kwargs)
cache[key] = (result, now)
return result
wrapper.clear = lambda: cache.clear()
return wrapper
return decorator真正难的从来不是“怎么存”，而是“什么时候不该存”——比如函数依赖全局状态、有副作用、或输入本身带时间戳，这些地方加缓存反而引入隐晦 bug。
