直接换 SECRET_KEY 不会崩，但旧 session、CSRF token、密码重置链接全部失效；Django 用其签名而非运行控制，新密钥仅作用于新请求，旧签名无法验证，导致用户登出、表单403、重置链接404；4.1+ 支持 SECRET_KEY_FALLBACKS 实现安全轮换。
直接换 SECRET_KEY 不会崩，但旧 session、CSRF token、密码重置链接会全部失效——除非你提前配置 fallback 机制。
SECRET_KEY 被改后为什么项目还能跑？
因为 Django 的 SECRET_KEY 主要用于签名（signing）和加密（如 session 数据、CSRF token、django.contrib.messages），不是运行时“开关”。只要新请求进来，Django 就用新密钥生成签名；但之前用旧密钥签过的东西（比如用户浏览器里的 sessionid Cookie），服务端就验不出来了。
- 用户会被强制登出（session 验证失败）
- 正在填写的表单可能触发 CSRF 失败（
403 Forbidden） - 已发送但未点击的密码重置邮件链接会 404
-
python manage.py check --deploy会警告你密钥是否为空、是否为默认值、是否硬编码在代码里
Django 4.1+ 如何安全轮换而不踢掉在线用户？
靠 SECRET_KEY_FALLBACKS：它是个列表，Django 按顺序尝试解签，第一个成功即通过。适合灰度切换或紧急轮换场景。
- 必须是字符串列表，每个元素都是合法的 50 字符随机字符串
- 旧密钥放后面，新密钥放最前面（优先用新密钥签名，兼容旧签名验证）
- 不能把开发环境的默认密钥（如
django-insecure-xxx）放进 fallback 列表 - 示例配置：
SECRET_KEY = 'new-50-char-random-string-here-...' # 当前主密钥
SECRET_KEY_FALLBACKS = [
'old-50-char-random-string-from-last-month',
'older-one-from-three-months-ago',
]轮换完成后，等所有活跃 session 过期（或手动清空 django_session 表），再从 SECRET_KEY_FALLBACKS 中移除旧项。
立即学习“Python免费学习笔记（深入）”；
为什么不能用同一个 SECRET_KEY 衍生数据库字段加密密钥？
这是密钥混用的典型错误。Django 的 SECRET_KEY 是框架级密钥，生命周期长、暴露面广（日志、监控、调试页面都可能意外泄露）；而数据库字段加密（如 Fernet）需要的是专用、隔离、可独立轮换的密钥，比如 ENCRYPTION_KEY。
-
SECRET_KEY泄露 → 整个认证体系崩塌（session、CSRF、重置链接全可伪造） -
ENCRYPTION_KEY泄露 → 只影响被加密的字段（如身份证号、手机号），可控范围小 - 两者绑定会导致轮换耦合：换一个就得同步换另一个，容易漏、难审计、易出错
- 正确做法：用
os.environ.get('ENCRYPTION_KEY')或config('ENCRYPTION_KEY')单独加载，绝不复用SECRET_KEY
环境变量 + python-decouple 是最简落地方案
硬编码 SECRET_KEY 在 settings.py 里是高危操作，尤其当项目进 Git —— 即便加了 .gitignore，也常有人误提交。用 python-decouple 加环境变量是最轻量、最易审计的解法。
- 安装：
pip install python-decouple - 在项目根目录放
.env文件（确保.gitignore包含它）：
SECRET_KEY=your-50-char-random-string-here DEBUG=False ALLOWED_HOSTS=example.com,api.example.com
- 在
settings.py中读取：from decouple import config→SECRET_KEY = config('SECRET_KEY') - 生成强密钥推荐命令：
openssl rand -base64 50 | tr -d '\n'（Linux/macOS）或用 Python：from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())
真正麻烦的从来不是“怎么换”，而是“换完之后哪些地方还在依赖旧签名”——session、缓存、第三方 token（如 JWT）、自定义签名 URL 都得一并梳理。没做 fallback 就直接切，等于给所有在线用户发了一张单程车票。
