asyncio中不可用functools.lru_cache，因其不支持await、返回协程且无并发安全；应改用aiocache等原生异步缓存库，支持TTL、分布式锁及多后端。
asyncio 里用 functools.lru_cache 会直接失效
它根本不是为异步设计的——遇到 await 就卡住，缓存返回的是协程对象而不是结果，调用方还得自己 await 一次，但下次再调用又生成新协程，完全不复用。更糟的是，lru_cache 内部没加锁，多任务并发读写缓存时可能把缓存项搞乱。
- 别包装
async def函数进lru_cache，哪怕加了@sync_to_async类似装饰也不行 - 真要轻量缓存且只读，可先
await执行完再缓存结果（即缓存的是值，不是协程） - 但凡涉及写操作、TTL、或跨协程共享，必须换真正支持 async 的库
推荐用 aiocache 而不是手写 asyncio.Lock + 字典
aiocache 不是简单套壳，它原生支持多种后端（内存、Redis、Memcached），每个后端都实现了带 TTL 的异步 get/set/del，且默认对 key 加锁防止击穿。自己用 dict + asyncio.Lock 很容易漏掉异常路径下的解锁，或者忘记清理过期项。
- 安装：
pip install aiocache - 最简内存缓存：
@cached(ttl=60)直接装饰async def函数 - Redis 后端需传
endpoint和port，连接池自动管理，不用手动await redis.close() - 注意：
ttl=0表示永不过期，但内存后端不会自动淘汰，可能撑爆内存
redis-py 4.0+ 的 from_url 支持 async，但得配 redis.asyncio
老版本 redis.Redis 是同步阻塞的，放进 async def 里等于把整个 event loop 拖垮。4.0+ 拆出了 redis.asyncio 子模块，它才是真正的异步客户端——所有方法名和同步版一致，但返回协程。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 别用
import redis然后调redis.Redis(...)，那是同步版 - 正确导入：
from redis.asyncio import Redis，然后redis = Redis.from_url("redis://localhost") -
set/get必须await，比如await redis.get("key")，否则拿到的是coroutine对象 - 连接池复用很重要：单例
Redis实例可被多个协程安全共用，不要每次请求都新建
缓存穿透和雪崩在异步下更隐蔽，得靠 aiocache 的 lock 参数兜底
同步环境里，一个请求查不到缓存去查 DB，其他请求可能排队等；异步环境下，几十个协程同时发现缓存空，全冲向 DB，DB 瞬间被打挂。这时候光靠 TTL 不够，得让第一个协程去加载，其余协程等它完成。
-
aiocache默认开启lock=True，同一 key 的并发请求会串行化加载 - 如果关了
lock（比如设lock=False），就要自己用asyncio.Lock套一层，但容易漏掉异常分支 - Redis 后端下，
lock实际是用SET key value NX EX 5实现的分布式锁，比内存锁更可靠
异步缓存最难的不是“怎么写”，而是“什么时候不该缓存”——比如用户会话数据带权限上下文，缓存前必须确认 key 是否包含足够隔离维度，否则 A 用户看到 B 用户的数据，这种错在异步高并发下更难复现。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
