用 cache_info() 方法可验证 lru_cache 是否命中，它返回含 hits、misses 等字段的命名元组；hits 增长即表示命中，但需注意参数稳定性、类型一致性及多线程/异步限制。
怎么知道 lru_cache 真的在命中？
靠猜不行，lru_cache 默认不暴露命中统计。你改了参数、加了 typed=True、甚至把 maxsize 调成 128，但缓存到底有没有起作用，得看真实调用行为。
最直接的办法是用 cache_info() 方法——它返回一个命名元组，含 hits、misses、maxsize 和 currsize 四个字段。
- 每次调用被缓存函数后，立刻查一次
func.cache_info()，观察hits是否增长 - 注意：只有显式调用该函数才会触发统计；装饰器本身不自动打点
- 如果
hits始终为0，大概率是参数没“稳定”（比如传了可变对象、dict或未冻结的dataclass）
lru_cache 为什么总 miss？常见参数和类型陷阱
缓存 miss 不等于代码写错了，更多是键（key）生成逻辑不满足哈希与相等性要求。
-
typed=False（默认）下，1和1.0被视为同一 key；设为True后才区分类型，适合多态输入场景 - 传入可变对象（如
list、dict）会直接抛TypeError: unhashable type，必须转成tuple或frozenset - 自定义类实例不会自动哈希，除非实现
__hash__和__eq__；更稳妥的是只缓存基础类型或NamedTuple/@dataclass(frozen=True) - 函数内部修改了外部可变状态（比如全局 dict），缓存结果可能“过期”，但
lru_cache不感知，也不会失效
如何在不改业务逻辑的前提下监控命中率？
硬加 print(func.cache_info()) 太糙，也污染日志。推荐封装一层轻量 wrapper：
立即学习“Python免费学习笔记（深入）”；
def tracked_cache(maxsize=128, typed=False):
def decorator(func):
cached_func = lru_cache(maxsize=maxsize, typed=typed)(func)
def wrapper(*args, **kwargs):
result = cached_func(*args, **kwargs)
info = cached_func.cache_info()
if info.hits + info.misses > 0:
hit_rate = info.hits / (info.hits + info.misses)
# 可发到 metrics、log，或只在 debug 模式下 print
if __debug__:
print(f"[{func.__name__}] hit_rate={hit_rate:.2%} ({info.hits}/{info.hits+info.misses})")
return result
wrapper.cache_info = cached_func.cache_info
wrapper.cache_clear = cached_func.cache_clear
return wrapper
return decorator
这样既保留原接口，又把统计逻辑抽离出来，上线时还能通过 __debug__ 控制是否启用。
高并发或长周期服务里，cache_info() 的值可信吗？
不可信——cache_info() 返回的是当前线程视角的快照，不是原子计数。在多线程/协程环境下，hits 和 misses 可能被多个调用者同时更新，导致微小偏差；更严重的是，如果你在异步任务里混用 lru_cache（比如在 async def 上直接装饰），缓存根本不起作用——因为 await 不是函数调用，而是协程对象构造过程，lru_cache 根本没机会介入。
- 异步场景必须用
aiocache、async_lru等专用库 - 想长期跟踪命中率，别依赖单次
cache_info()，应定期采样（比如每 100 次调用汇总一次） -
maxsize=None看似“无限”，但实际仍受限于内存和 Python 对象生命周期；若缓存键持续增长，可能引发内存缓慢泄漏
缓存命中率不是调出来就完事的数字，它是函数输入稳定性、类型设计合理性、以及运行时环境一致性的综合投影。盯着 hits 增长容易，但真正难的是让 misses 那些 case 变得可解释、可收敛。
