Django配置中能否将SECRET_KEY设置为get_random_secret_key()？

针对如下配置写法：

# settings.py
from django.core.management.utils import get_random_secret_key
SECRET_KEY = get_random_secret_key()

这属于明确的不良实践，生产环境严禁使用，仅可在无数据留存的临时本地测试场景下临时凑合用。

Django的SECRET_KEY是框架所有签名逻辑的根信任凭据，用来给session、CSRF令牌、密码重置链接、邮件验证链接、各类临时签名凭据做加密签名，一旦密钥发生变化，所有之前用旧密钥签发的凭据会全部直接失效。
上述配置每次启动Django进程都会生成一个全新的随机密钥，会直接引发几个必现故障：

• 多实例/多worker部署直接不可用：不管你是用多worker模式跑gunicorn/uWSGI，还是用容器做横向扩容，每个独立进程/实例都会生成自己的独立密钥，用户的请求刚在A实例拿到合法的CSRF token，下一次转发到B实例就会直接报403校验失败，登录、表单提交这类操作根本没法正常完成。
• 服务重启就会导致全站用户状态失效：每次重启应用进程都会生成新密钥，所有用户的登录会话、记住登录状态的cookie、还在有效期内的密码重置/邮箱验证链接会全部作废，用户会被强制踢下线，点击合法的操作链接会直接提示凭据无效。
• 故障无法恢复：动态生成的密钥不会持久化存储，一旦进程异常崩溃重启，你根本找不回之前的密钥，所有用旧密钥签名的业务数据没有任何恢复的可能。

补充说明：get_random_secret_key()方法本身的设计用途，是给django-admin startproject初始化新项目的时候，生成一个固定的初始密钥写入默认settings.py文件，从来不是让你在运行时动态生成替换的。

只有当你跑一次性的本地临时Demo、单元测试，服务生命周期极短、完全不留存用户数据、也不需要多实例部署的时候，临时这么写图方便不会有大问题，但只要是要对外提供服务、需要持久化用户状态的环境，都绝对不要用这种写法。

生产环境请使用固定的、复杂度足够的密钥，从环境变量或者权限严格管控的本地配置文件读取加载，不要硬编码在代码仓库里；密钥不要随意更换，确需轮换的时候要提前做好多密钥兼容的过渡方案，避免直接导致业务故障。

内容的提问来源于stack exchange，提问作者Amin Ba