17370845950

手写缓存装饰器旨在理解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

并发环境下缓存读写怎么不丢数据？

多个线程/协程同时调用同一函数，且缓存未命中时，若不做控制，会重复执行原函数并覆盖彼此结果。

• 最轻量解法：用 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。