最稳妥的缓存键生成是为业务加前缀（如api:posts:）和版本号（v1:），对影响结果的参数排序后用md5哈希，避免request.args直接转字符串导致顺序不稳；必须配connectionpool复用连接，空结果需设短过期缓存防雪崩。
直接用 redis.Redis 手动缓存最可控，但要注意键生成、序列化和连接池——别一上来就用 @cache.cached，它在复杂参数或异步场景下容易失效。
缓存键怎么生成才不冲突又可预测
键名不是随便拼的，user:123 这种固定结构适合简单 ID 查询，但遇到带分页、筛选参数的接口（比如 /api/posts?tag=python&page=2），必须把所有影响结果的参数纳入键计算。
- 错误做法：
f"posts:{request.args}"——request.args是ImmutableMultiDict，str()结果不稳定，不同顺序会生成不同键 - 推荐做法：用
hashlib.md5对排序后的参数键值对做哈希，例如md5(b"page=2&tag=python")，再转成 hex 字符串作为后缀 - 额外建议：加业务前缀（如
api:posts:）和版本号（如v1:），方便后续批量清理或灰度切换
redis.Redis 初始化时必须配连接池
每次请求都新建 redis.Redis(host='localhost', port=6379) 会导致连接数爆炸，尤其在 Flask/Gunicorn 多 worker 场景下。连接耗尽后你会看到 ConnectionError: Error 24 connecting to localhost:6379. Too many open files.
提示词大师-python版
下载
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 必须用
redis.ConnectionPool：创建一次，全局复用 - 关键参数：
max_connections=20（根据并发量调）、decode_responses=True（避免手动.decode()） - 示例：
pool = redis.ConnectionPool(host='localhost', port=6379, db=0, max_connections=20, decode_responses=True) r = redis.Redis(connection_pool=pool)
缓存读写逻辑要覆盖“空值”和“异常”两种失败路径
只处理“缓存命中”和“查库写缓存”是不够的。数据库查不到（返回 None）或查询抛异常时，如果不缓存，下次请求还会重试，可能触发雪崩。
- 空结果也要缓存，但用短过期时间（如 60 秒），避免长期阻塞真实数据更新：
r.setex(key, 60, json.dumps(None)) - 数据库异常时，不要写缓存，但可以 fallback 到旧缓存（如果存在）：
if not cached: cached = r.get(f"{key}:fallback") - 务必用
try/except包住数据库查询，防止未捕获异常导致缓存逻辑跳过
Flask-Caching 的 @cache.cached 什么时候不能用
这个装饰器对简单视图函数友好，但遇到以下情况会出问题：
- 函数参数含不可哈希类型（如
dict、list）——装饰器内部用hash(args)会直接报TypeError - 异步视图（
async def）——Flask-Caching不支持，得换aioredis+ 手写逻辑 - 需要按用户身份隔离缓存（比如登录态不同返回不同内容）——默认不包含
session或request.headers，得自己扩展make_cache_key - 缓存键需动态计算（比如根据 URL 参数是否存在某字段决定是否走缓存）——装饰器做不到条件性缓存
真正需要稳定性和灵活性的地方，手写三行 r.get/r.setex 比强套装饰器更靠谱。最容易被忽略的是连接池配置和空结果缓存策略——这两个点没处理好，缓存反而会放大故障。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
