cache 与 lru_cache怎么配置或排查

Python 里看到 @cache 和 @lru_cache，先记住一个实用判断：cache 等价于 lru_cache(maxsize=None)，不会主动淘汰旧值；lru_cache 默认最多保留 128 个最近调用结果，更适合长期运行的服务。配置前先估算键的数量，再用 cache_info() 看命中是否真的改善。

先选对 cache：无限缓存还是有限 LRU

@cache 适合递归计算、有限枚举或进程生命周期内不会持续扩张的纯函数。它省去了淘汰判断，但每个参数组合都会留下引用。Web 服务、任务进程或多租户程序通常应该优先使用有限的 LRU，避免输入键不断增长。

from functools import cache, lru_cache

@cache
def country_code(name: str) -> str:
    # 键集合来自固定配置，结果稳定，适合轻量的无限缓存
    return {"中国": "CN", "日本": "JP"}.get(name, "UNKNOWN")

@lru_cache(maxsize=256, typed=True)
def feature_flag(tenant_id: int, flag_name: str) -> bool:
    # 生产服务给容量上限；typed=True 让不同类型的立即参数分别计数
    return (tenant_id, flag_name) in {(7, "new-home"), (9, "export")}

这里的 maxsize=256 不是性能定律，而是一个可观察的初始容量。typed=True 只区分函数的直接参数类型，不会递归比较容器内部的每一层类型。两种装饰器都要求位置参数和关键字参数可哈希，因此 list、dict 不能直接作为缓存键。

参数写法不统一，为什么会让命中率变低

缓存键由调用参数组成。对于同一个函数，feature_flag(7, "new-home") 与 feature_flag(tenant_id=7, flag_name="new-home") 不应在业务层随意混用；关键字参数顺序不同也可能被视为不同调用。建议在服务边界统一一种调用风格，并在进入缓存函数前把可变输入规整成字符串、整数或元组。

还要检查函数本身是否值得缓存：带副作用、依赖 time()、random() 或外部实时状态的函数不适合直接装饰。返回的列表或字典也会被重复交给调用方；调用方修改它，下一次命中可能拿到被改过的对象。

cache_info() 怎么判断缓存到底有没有生效

装饰后的函数自带三个很有用的运维接口。cache_info() 返回 hits、misses、maxsize 和 currsize；cache_parameters() 核对当前的 maxsize 与 typed；cache_clear() 清除已有记录。它们比凭感觉调大容量更可靠。

def inspect_cache() -> None:
    # 只读取指标，不改变缓存；可接入启动检查或低频诊断日志
    info = feature_flag.cache_info()
    params = feature_flag.cache_parameters()
    print({
        "hits": info.hits,
        "misses": info.misses,
        "currsize": info.currsize,
        "maxsize": params["maxsize"],
        "typed": params["typed"],
    })

    # 配置或租户数据发生变化时，再由明确的管理动作清空缓存
    # feature_flag.cache_clear()

如果 misses 持续增加而 currsize 很快达到 maxsize，先检查键是否包含时间、随机值或过细的请求字段；不要只把容量从 256 改成更大的数字。若怀疑装饰器改变了函数行为，可以用 feature_flag.__wrapped__(7, "new-home") 绕过缓存，对比函数本体的返回。

上线前的缓存检查清单

最后不要把进程内的 cache 或 lru_cache 当成带 TTL 的共享缓存：它们不自动跨进程同步，也不会按时间过期。并发下底层缓存结构保持一致，但相同键的计算函数仍可能在首次填充期间被调用多次。发布前把这些边界写进清理策略和监控说明，排障会比盲目改 maxsize 快得多。

相关问题

cache 可以设置最大容量吗？

不能直接给 @cache 传容量参数；需要容量上限时改用 @lru_cache(maxsize=...)。

lru_cache 能按时间自动过期吗？

标准装饰器没有 TTL 参数。需要时间失效时，应在业务层设计清理或选择专门的缓存组件。

为什么 lru_cache 装饰异步函数容易出问题？

它缓存的是协程对象，而不是自动缓存异步结果；异步函数应单独设计并发、失效和共享缓存策略。