django的session不能直接用redis-py连接，因其session_engine仅支持预定义后端类（如django.contrib.sessions.backends.cache），且依赖django.core.cache统一接口，必须通过caches字典配置django-redis封装的rediscache后端，否则request.session无法自动管理cookie、生命周期及超时策略。
不能直接用 Python 原生驱动（比如 redis-py）连接 Redis 实现 Django 的 Session 存储 —— Django 的 Session 后端不接受裸 redis.Redis 实例，必须通过兼容的缓存后端封装。
为什么不能直接用 redis.Redis 初始化 Session？
Django 的 SESSION_ENGINE 只认预定义的后端类路径，如 django.contrib.sessions.backends.cache 或 django.contrib.sessions.backends.cached_db。这些后端内部依赖 django.core.cache 的统一接口，而该接口要求缓存配置走 CACHES 字典，不是手动传入一个 redis.Redis 对象。
如果你绕过 CACHES、自己在视图里用 redis.Redis(host='127.0.0.1', port=6379) 读写 key，那只是“自己操作 Redis”，和 Django 的 request.session 完全无关 —— 不会自动设置 cookie、不会触发 session middleware 的生命周期、也不会受 SESSION_COOKIE_AGE 等控制。
django-redis 是唯一推荐的 Redis 集成方式
要让 Django 的 session 真正跑在 Redis 上，必须用 django-redis 提供的缓存后端，它实现了 Django 缓存协议，并把底层交给 redis-py。这不是“可选方案”，而是当前 Django 生态的事实标准。
- 安装：
pip install django-redis - 配置
CACHES（必须）：CACHES = { "default": { "BACKEND": "django_redis.cache.RedisCache", "LOCATION": "redis://127.0.0.1:6379/1", "OPTIONS": { "CLIENT_CLASS": "django_redis.client.DefaultClient", } } } - 设置 session 引擎：
SESSION_ENGINE = "django.contrib.sessions.backends.cache"或"django.contrib.sessions.backends.cached_db" - 确保
SessionMiddleware在MIDDLEWARE中启用（默认已有）
常见错误：混淆 cache 和 cached_db 后端
这两个都依赖 Redis，但行为差异极大，容易导致数据丢失或调试困难：
-
SESSION_ENGINE = "django.contrib.sessions.backends.cache"：只存 Redis，无兜底。Redis 重启、内存淘汰、超时都会清空 session —— 生产环境慎用 -
SESSION_ENGINE = "django.contrib.sessions.backends.cached_db"：每次写 session 同时写 Redis + DB；读优先 Redis，失效时 fallback 到 DB。需要提前运行python manage.py migrate创建django_session表 - 漏掉
INSTALLED_APPS中的'django.contrib.sessions'→ 报错AppRegistryNotReady -
LOCATION写成redis://localhost:6379/1但本地 hosts 没配localhost解析 → 连接超时，且错误日志可能只显示 “Connection refused”，不提示是 DNS 问题
验证 Redis Session 是否生效
别只看是否报错，要实测数据落点：
- 登录后，在 Django shell 中执行：
from django.contrib.sessions.models import Session Session.objects.count() # cached_db 下应有记录；cache 下应为 0
- 用 redis-cli 查 Redis：
redis-cli -p 6379 -n 1 keys "django.contrib.sessions.cache:*"
（注意数据库编号要和LOCATION一致） - 检查响应 header 是否含
Set-Cookie: sessionid=xxx; Path=/; HttpOnly; Secure（Secure要求SESSION_COOKIE_SECURE=True且启用了 HTTPS）
真正容易被忽略的是：Django 的 session ID cookie 默认不带 SameSite 属性，若前端跨域调用 API，需显式设 SESSION_COOKIE_SAMESITE = 'Lax' 或 'None'（后者强制要求 SESSION_COOKIE_SECURE=True）。这个细节在开发联调阶段经常引发 403 或 session 无法携带。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
