SimpleCache生产无效，因其为线程本地字典，多worker间不共享且无法主动失效；Redis后端需显式配置URL，否则静默退化为内存缓存。
直接上结论：对读多写少、参数固定、无用户态差异的接口，用 Redis 后端 + @cache.cached() 是见效最快的方式；SimpleCache 只能用于开发验证，生产环境一上就失效。
为什么 SimpleCache 在生产里基本等于没缓存
它本质是线程本地的 Python 字典，gunicorn 开 4 个 worker 就有 4 套完全隔离的缓存，互相不共享。你改了数据，旧值还在其他进程里躺着——用户看到的就是脏数据。更关键的是：cache.delete_memoized() 对它完全无效，无法主动失效。
- 开发阶段可设
CACHE_TYPE = 'SimpleCache'快速跑通逻辑 - 测试/预发必须切到
redis或memcached - 生产配置里禁止出现
'SimpleCache'字样
@cache.cached(timeout=) 的 timeout 不是 TTL
这个参数控制的是“最长不刷新时长”，不是到点自动删。行为是：首次请求写入缓存，之后所有请求只要在 timeout 内都返回缓存值；超时后，**下一个请求会穿透缓存，重新执行函数，并把新结果覆盖旧缓存**——也就是“懒刷新”。
- 如果接口每秒被调 100 次，
timeout=60，那第 61 秒那个请求会卡住，其他 99 个都在等它 - 关键接口建议加
refresh=True（需 Flask-Caching ≥ 2.0.0），启用后台异步刷新 - 别盲目设大
timeout，先看数据更新频率：用户列表每 5 分钟变一次，timeout就别设 3600
带 query 参数的接口怎么缓存才不串 key
默认 @cache.cached() 只按路径缓存，/api/users?role=admin 和 /api/users?role=guest 会共用一个缓存 key，结果互相污染。
- 必须显式指定
key_prefix，比如@cache.cached(key_prefix='users_list') - 再配合
query_string=True，让 Flask-Caching 自动把 query 参数拼进 key - 或手动用
@cache.memoize()，它默认基于函数参数生成 key，更适合带参场景 - 注意过滤敏感参数：如
token、sign这类不该参与缓存 key 计算的字段，得提前从 request.args 剥离
Redis 后端必须显式配 URL，否则静默退化
很多人设了 CACHE_TYPE = 'redis' 就以为连上 Redis 了，结果上线发现缓存重启就丢——因为 Flask-Caching 2.0+ 默认不 fallback 到 localhost，它会静默退回到内存缓存，完全不报错。
-
CACHE_TYPE必须是字符串'redis'，不是模块名或类名 - 必须提供
CACHE_REDIS_URL，例如redis://localhost:6379/1；末尾/1是数据库编号，别漏掉 - 如果 Redis 要密码，写成
redis://:mypass@localhost:6379/1；冒号前留空表示无用户名 - 不配
CACHE_REDIS_URL时，它会尝试连localhost:6379，但库号是 0，容易被其他脚本清空
最常被忽略的一点：缓存是否生效，和你有没有装 Redis 客户端、连接池怎么建、key 设计是否区分业务维度，全有关联。光写个 @cache.cached() 不检查后端配置，大概率白忙活。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
