async-lru能直接装饰async def函数，但必须用@alru_cache()（带括号），否则装饰器未生效；它基于asyncio.Lock保证并发安全，缓存键由可哈希参数生成，不支持TTL、不可哈希类型或session实例传参。
async-lru 能否直接装饰 async def 函数
能，但必须用 @alru_cache()（注意末尾括号），不是 @alru_cache。漏掉括号会导致装饰器未被调用，函数仍无缓存行为，且不会报错——这是最常踩的坑。
它只支持 Python 3.7+，且要求被装饰函数返回协程对象（即 await 后能拿到结果），不支持直接缓存 async for 或流式响应。
-
alru_cache()是异步版functools.lru_cache()，底层用asyncio.Lock保证并发安全 - 缓存键基于位置参数和关键字参数的值生成，
self或cls不参与计算（所以类方法需谨慎） - 不支持对
**kwargs中不可哈希类型（如dict、list）做缓存，会抛TypeError: unhashable type
如何缓存带 session 或 headers 的 HTTP 请求
不能直接缓存 aiohttp.ClientSession.get() 这类底层调用，因为 ClientSession 实例本身不可哈希；必须封装成纯函数，把 URL、headers、params 等可哈希参数显式传入。
典型错误是把 session 当作参数传进 @alru_cache() 装饰的函数——这会让缓存失效或崩溃。
立即学习“Python免费学习笔记（深入）”；
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 正确做法：提取请求逻辑为独立 async 函数，参数仅含
url、timeout、headers（且headers用frozenset(headers.items())转为可哈希类型） - 避免传入
session，改由函数内部从全局或上下文获取已复用的ClientSession - 若需区分用户身份缓存，把
user_id或token_hash作为参数传入，而非从 request 对象动态读取（那会破坏缓存一致性）
缓存失效与手动清除怎么做
async-lru 没有内置 TTL 或自动过期机制，所有缓存项永久存在，直到内存溢出或手动清理——这点和 Redis 缓存完全不同，容易误判为“缓存没生效”或“数据陈旧”。
清除方式只有两种：重置整个缓存，或按签名精准删除。
- 清空全部：
your_func.cache_clear() - 删指定调用：
await your_func.cache_remove(arg1, arg2, key="value")（需确保参数完全一致） - 查看命中率：
your_func.cache_info()返回CacheInfo(hits=12, misses=3, maxsize=128, currsize=5) - 不支持基于时间/条件的自动失效，如有此需求，得自己套一层包装逻辑（例如在函数开头检查时间戳）
和 Redis 异步缓存比有什么实际差异
本质区别在于作用域：async-lru 是进程内内存缓存，快但不共享；Redis 是跨进程/跨服务的外部缓存，慢一点但一致性强。
本地缓存适合高频读、低更新、容忍短暂不一致的场景（如配置查询、静态元数据）；一旦涉及多实例部署或强一致性要求（如库存、订单状态），单靠 async-lru 无法解决。
-
async-lru平均读取延迟 ≈ 0.1ms，Redis（同机房）≈ 1–5ms - 重启进程后
async-lru全丢，Redis 持久化后可恢复 - 无法用
async-lru实现“一个写、多个读”的缓存穿透防护，得配合分布式锁或二级缓存方案
