不能将 SECRET_KEY 或数据库密码写入 settings.py，因为 Git 历史难以彻底清除、.gitignore 不可靠、CI/CD 缓存和镜像层可能泄露；必须运行时通过环境变量注入，禁用 .env 文件，Docker 用 -e 或 environment: 显式传入，Kubernetes 用 Secret + envFrom:。
为什么不能把 SECRET_KEY 或数据库密码写进 settings.py
因为一旦提交到 Git，敏感信息就永久留在历史记录里，即使删掉也难彻底清除。Django 的 settings.py 默认是 Python 模块，直接执行时会暴露所有变量——哪怕加了 .gitignore，本地误操作、CI/CD 构建缓存、容器镜像层残留都可能泄露。
真正安全的起点是：**所有生产环境敏感值必须在运行时注入，且不经过源码路径**。
- 使用操作系统级环境变量（
os.environ）是最轻量、最通用的方式 - 避免用
python-decouple或django-environ的.env文件——它们在生产中容易误提交或挂载错误 - 如果用 Docker，确保
docker run -e或docker-compose.yml的environment:块显式传入，而不是靠volumes:挂载.env - Kubernetes 用户应优先用
Secret对象 +envFrom:，而非env:下明文写value:
如何让 Django 从环境变量读取配置并做类型转换与校验
Django 本身不提供环境变量解析工具，但可以靠 os.environ.get() + 显式类型转换 + 异常拦截来守住底线。关键不是“自动识别”，而是“出错时立刻失败”。
示例片段（放在 settings/base.py 中）：
立即学习“Python免费学习笔记（深入）”；
python-flask-vue-creator
下载
创建 Flask + Vue.js 全栈项目，采用单端口架构、uv 依赖管理、结构化日志和生产级前端设计。当用户要求以下操作时触发：创建新的 Flask+Vue 项目、搭建 Web 应用、构建全栈 Python+Vue 应用、初始化 Flask Web 项目、设置单端口 Flask 前后端项目。触发词：新建项目、创建项目、搭建项目、Flask项目、Vue项目。
# 强制要求 SECRET_KEY 存在，否则启动报错
SECRET_KEY = os.environ.get('SECRET_KEY')
if not SECRET_KEY:
raise ValueError('SECRET_KEY must be set in environment')
<h1>转换为布尔值，支持 'true'/'false'/'1'/'0'，默认 False</h1><p>DEBUG = os.environ.get('DEBUG', 'false').lower() in ('true', '1')</p><h1>数据库 URL 解析（推荐 django-environ 的 parse()，但只用于解析，不加载 .env）</h1><p>import environ
env = environ.Env()
DATABASES = {
'default': env.db('DATABASE_URL', default='sqlite:///db.sqlite3')
}
- 永远不要用
os.environ.get('KEY', 'fallback')给敏感字段设默认值——这会让密钥变成硬编码 - 对布尔、整数等类型，用
.get()后立刻转换，并捕获ValueError（比如int(os.environ['PORT'])） -
django-environ的env.db()和env.cache()很实用，但它内部仍依赖os.environ——重点是别让它去读文件
如何防止 DEBUG=True 在生产环境意外开启
这是 Django 最经典的安全疏漏：DEBUG=True 会暴露完整 traceback、内存变量、SQL 查询，甚至允许任意代码执行（当 ALLOWED_HOSTS 配置不当+调试面板启用时）。
- 在入口
settings/production.py里强制覆盖：DEBUG = False，且不依赖环境变量控制 - 用
ALLOWED_HOSTS = os.environ.get('ALLOWED_HOSTS', '').split(',')，但必须校验非空：if not ALLOWED_HOSTS: raise ValueError('ALLOWED_HOSTS cannot be empty') - 检查是否启用了
django-debug-toolbar：它不应出现在生产INSTALLED_APPS中，更不能靠环境变量动态开关 - CI/CD 流水线里加检查步骤：
grep -q 'DEBUG.*=.*True' settings/production.py || exit 1
容器与云平台下环境变量的实际落地方案
环境变量不是“设了就安全”，而要看它怎么进进程。不同部署方式风险点完全不同。
- Docker：用
docker run -e SECRET_KEY=xxx是最干净的；避免--env-file，除非该文件本身由 Secret 管理系统生成且生命周期极短 - ECS/EKS：AWS Parameter Store 或 Secrets Manager 应通过 task role 获取，再注入容器环境——不要用
ecs-params.yml明文写secrets:映射 - Serverless（如 AWS Lambda）：Lambda 的环境变量加密功能必须开启 KMS key，且函数执行角色要有
kms:Decrypt权限 - 注意
os.environ在多进程模型（如 Gunicorn worker）中是进程级隔离的，但若用fork启动，父进程读取的变量会被子进程继承——所以务必在 worker 进程启动前完成读取
最易被忽略的一点：环境变量在 shell 中可能被 ps aux 或 /proc/[pid]/environ 短暂可见。虽然现代容器运行时做了掩码，但在调试时用 print(os.environ) 或日志输出变量值，等于主动泄密。
