根本原因是location格式错误或redis不可达导致django静默降级到locmemcache；需用redis://127.0.0.1:6379/1格式、确保服务可达、清理错误options，并开启debug日志验证连接。
为什么改了 CACHES 配置却没走 Redis？
常见现象是：明明把 BACKEND 换成了 django_redis.cache.RedisCache，也装了 django-redis，但 cache.get() 依然返回 None，或日志里压根没看到 Redis 连接请求。
根本原因通常是 LOCATION 格式写错，或 Redis 服务不可达但 Django 默认静默降级到本地内存缓存（LocMemCache）。
-
LOCATION必须是完整 URL 形式：redis://127.0.0.1:6379/1（推荐），不是localhost:6379或字典形式 - 确认
redis-server正在运行，且端口可被 Django 进程访问（Docker 环境注意网络命名空间） - 删掉
OPTIONS里多余的'CLIENT_CLASS'或拼写错误的键，它会触发 silent fallback - 加一行
LOGGING配置临时打开缓存后端日志，验证是否真连 Redis：LOGGING = { 'version': 1, 'handlers': {'console': {'class': 'logging.StreamHandler'}}, 'loggers': {'django.core.cache': {'handlers': ['console'], 'level': 'DEBUG'}}}
CACHES 的关键参数怎么设才不拖慢 QPS？
默认配置下，Redis 缓存可能反而比数据库还慢——尤其在高并发读场景。问题常出在连接池和序列化上。
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
-
'CONNECTION_POOL_KWARGS'必须显式设置：{'max_connections': 50, 'retry_on_timeout': True}，否则每次get都新建连接 -
'SERIALIZER'别用默认的django_redis.serializers.PickleSerializer，换成django_redis.serializers.JSONSerializer（需确保缓存值能 JSON 序列化），避免 pickle 反序列化开销和安全风险 -
'KEY_PREFIX'建议设为项目名（如'myapp'），避免多项目共用 Redis DB 时 key 冲突，但别太长，影响网络传输 - 不要在
OPTIONS里配'COMPRESSOR'—— gzip 压缩对小数据（如 session、token）得不偿失，CPU 反而吃紧
哪些缓存操作会意外绕过 Redis？
Django 的缓存抽象层有几处“暗坑”，表面调用 cache，实际没发请求到 Redis。
-
cache.set('key', obj, timeout=0)：timeout=0 表示“永不过期”，但某些 Redis 后端会把它转成SET key val（无 EX），而cache.get()可能因内部逻辑误判为未命中 -
cache.add()在 key 存在时直接返回False，不抛异常，但不会触发 Redis 的SETNX原子性保障（取决于后端实现） - 使用
@cache_page时，如果视图返回HttpResponse且含Vary头，Django 会按 header 组合生成 key，但若 header 值含非法字符（如换行），key 会被截断或污染，导致缓存失效 - 测试环境启用了
DEBUG=True，部分中间件（如CommonMiddleware）会跳过缓存逻辑，线上务必关掉
如何验证 Redis 缓存真正在提升 QPS？
别只看 cache.get() 返回值，要从链路层确认流量是否真正打到 Redis，并量化收益。
- 用
redis-cli monitor实时抓包，观察GET/SET命令频次，对比开启缓存前后的差异 - 在
settings.py加'KEY_FUNCTION': lambda key, key_prefix, version: f'{key_prefix}:{version}:{key}'，统一 key 格式，方便redis-cli --scan --pattern 'myapp:*'统计总量 - 用
django-silk或自定义中间件记录每次cache.get耗时，抽样看 P95 是否稳定在 - 压测时关注 Redis 的
connected_clients和used_memory_peak_human，内存暴涨或连接数卡在上限，说明连接池或 key 泄漏
Redis 缓存不是开箱即用的银弹，CACHES 配置只是起点，真正影响 QPS 的是连接复用、序列化路径、key 设计和监控闭环——漏掉任何一环，都可能让缓存变成性能黑洞。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
