优先选 @lru_cache（默认 maxsize=128），因 functools.cache 等价于 @lru_cache(maxsize=none)，易致内存泄漏；禁用含 dict/list 参数的函数缓存；多进程下 cache_clear() 无效，应改用 redis 等共享缓存。
缓存失效策略选 @lru_cache 还是 functools.cache？
@lru_cache 和 functools.cache 都能做函数级缓存，但行为差异直接影响线上稳定性。前者默认有容量上限（maxsize=128），后者等价于 @lru_cache(maxsize=None) —— 意味着无限增长，可能吃光内存。
常见错误现象：用 functools.cache 缓存带参数的数据库查询函数，参数组合多、生命周期长，几小时后 RSS 暴涨 2GB。
使用场景建议：
-
@lru_cache(maxsize=128)：适合参数空间小、结果复用率高的纯计算（如解析固定格式字符串） -
functools.cache：仅限参数极少且确定不会膨胀的场景（如单例工厂函数） - 绝对不要用于含
dict/list参数的函数 —— 因为不可哈希，会直接抛TypeError: unhashable type
如何安全地让缓存支持可变参数（比如 **kwargs）？
@lru_cache 原生不接受可变参数，直接加装饰器会报 TypeError: unhashable type: 'dict'。核心矛盾在于：缓存键必须是可哈希的，而 dict 和 list 不是。
立即学习“Python免费学习笔记（深入）”；
解决思路不是“绕过哈希”，而是“构造可哈希键”：
- 把
**kwargs转成排序后的frozenset(items())，或序列化为tuple(sorted(kwargs.items())) - 对
*args中的列表/字典，用json.dumps(arg, sort_keys=True)转字符串再哈希（注意：仅限 JSON-safe 数据） - 更稳妥的做法是显式定义缓存键生成逻辑，不用自动推导
示例片段：
DESTOON B2B网站管理系统是一套完善的B2B(电子商务)行业门户解决方案。系统基于PHP+MySQL开发，采用B/S架构，模板与程序分离，源码开放。模型化的开发思路，可扩展或删除任何功能；创新的缓存技术与数据库设计，可负载千万级别数据容量及访问。
def cache_key(*args, **kwargs):
return (args[0], frozenset(sorted(kwargs.items())))
@lru_cache(maxsize=100)
def expensive_call(_key, *ignored): ...
——把键逻辑抽出来，避免装饰器黑盒误判。
cache_clear() 在多线程下为什么没用？
cache_clear() 是线程安全的，但它只清调用方所在 Python 解释器中的缓存副本。在 gunicorn/uwsgi 多 worker 场景下，每个 worker 是独立进程，各自维护一份 @lru_cache 实例 —— 调一个 worker 的 cache_clear()，其他 worker 完全无感。
常见错误现象：后台触发了 cache_clear()，但用户请求仍返回旧数据，查日志发现只有主进程清了，子进程缓存岿然不动。
真正有效的做法：
- 改用外部缓存（Redis）+ 主动失效机制，所有 worker 共享同一份缓存状态
- 或改用进程间共享内存方案（如
multiprocessing.Manager+ 自定义缓存容器），但复杂度陡增 - 简单服务可考虑降级为“TTL 缓存”，用
time.time()控制过期，不依赖清除动作
用 redis-py 做分布式缓存时，键名设计踩过哪些坑？
缓存键不是越详细越好，也不是越短越好。关键是“可预测性”和“可清理性”。
容易踩的坑：
- 直接用原始参数拼接键名，比如
f"user:{user_id}:profile"，但user_id是 UUID 或长整型时，键名过长且难以批量操作 - 忘记对参数做标准化：同一语义的输入（如
"foo"和b"foo"）生成不同键，导致缓存击穿 - 没预留命名空间，后期想批量
FLUSHDB或KEYS user:*:profile时发现键名混杂、无法收敛
推荐做法：
- 所有键统一前缀 + 业务域 + 类型 + 标准化参数（如强制转小写、去空格、截断超长字段）
- 示例：
"cache:user:profile:v2:{str(user_id).zfill(10)}" - 关键参数必须经过
hashlib.md5()或base64.urlsafe_b64encode()编码，避免特殊字符和长度失控 - 所有缓存操作封装进类方法，禁止裸写
redis_client.get(...)，否则键逻辑散落各处，治理无从谈起
缓存从来不是加个装饰器就完事的事。最麻烦的永远不在“怎么存”，而在“什么时候删”“删不删得干净”“删错了怎么办”。工程化治理的本质，是把不确定性变成可追踪、可审计、可灰度的动作。
