推荐按环境拆分 settings 文件：base.py 抽公共配置，development.py 和 production.py 各覆差异项；通过 django_settings_module 指定，敏感配置（如 secret_key）必须从环境变量或 secrets backend 读取，严禁硬编码。
用 settings.py 做环境判断容易出错
直接在 settings.py 里写 if DEBUG: 或读取 os.environ 判断环境，短期看着省事，但很快会失控——比如某天你发现生产环境也加载了开发用的 django-debug-toolbar，或者数据库密码被硬编码进 git。
- 环境变量读取要早于 Django 初始化，否则
DEBUG、DATABASE_URL等关键配置可能失效 -
DEBUG=True在生产环境启用会暴露敏感路径和变量名，nginx 日志里都可能漏出堆栈 - 别用文件存在性判断（如
if os.path.exists('prod.py'):），docker 容器里路径容易错位
推荐做法：按环境拆成多个 settings 文件 + 公共基类
把通用配置抽到 base.py，再分别建 development.py 和 production.py，每个只覆盖差异项。启动时通过 DJANGO_SETTINGS_MODULE 指定。
-
base.py放INSTALLED_APPS、中间件骨架、静态文件基础路径等不随环境变的内容 -
production.py必须重写SECRET_KEY（从环境变量读，绝不用默认值）、DEBUG=False、ALLOWED_HOSTS、SECURE_*系列开关 -
development.py可以加'debug_toolbar'，但记得检查INTERNAL_IPS是否匹配容器网络 IP（比如 Docker 中常是'172.17.0.1'）
DJANGO_SETTINGS_MODULE 设置时机和常见陷阱
这个环境变量必须在 Django 加载前就生效，否则它会 fallback 到默认的 settings.py，你写的分离逻辑就白搭。
- 命令行启动时，用
DJANGO_SETTINGS_MODULE=myproject.settings.production python manage.py runserver——注意顺序，变量要在python前置 - gunicorn 启动时，加
--env DJANGO_SETTINGS_MODULE=myproject.settings.production，别只靠.env文件，Gunicorn 不自动读它 - 如果用了
python-decouple或django-environ，它们只是帮你读环境变量，不替代DJANGO_SETTINGS_MODULE的作用
敏感配置别进代码，用环境变量或 secrets backend
SECRET_KEY、数据库密码、API 密钥这些，一旦写死在 production.py 里，CI/CD 流水线或镜像构建时就可能泄露。
- 用
os.environ.get('SECRET_KEY')读取，启动容器时通过-e SECRET_KEY=xxx注入 - K8s 环境优先用
Secret挂载为文件，然后在production.py中用open('/run/secrets/django_secret').read().strip() - 避免在
base.py里给敏感字段设默认值（如SECRET_KEY = os.environ.get('SECRET_KEY', 'dev-key-for-local')），生产部署时容易忘记删掉默认值
环境拆分最难的不是结构，是让所有人（包括你自己下周）都记得每次改配置时，到底该动哪个文件、往哪加环境变量、在哪验证是否生效。漏掉一个 SECURE_HSTS_SECONDS 或多写一个逗号导致 ALLOWED_HOSTS 解析失败，线上就挂。