必须将settings设为合法python包:根目录删旧settings.py,新建settings/含__init__.py;base.py中base_dir需向上多一层;dev.py/prod.py用from .base import *继承并显式覆盖关键配置;secret_key等敏感项严禁写死,须通过环境变量注入且base.py不设fallback默认值。

settings 目录结构怎么组织才不会启动报错
必须确保 settings 是一个合法的 Python 包,否则 Django 找不到模块。根目录下不能留着旧的 settings.py,否则容易被误加载;同时要删掉它或重命名(比如 settings.py.bak),避免冲突。
正确结构是:
myproject/ ├── manage.py ├── myproject/ # 项目包(含 __init__.py) │ ├── __init__.py │ ├── settings/ # 新建的 settings 包 │ │ ├── __init__.py # 必须存在,可为空 │ │ ├── base.py │ │ ├── dev.py │ │ └── prod.py │ └── ...
base.py 里要重定义 BASE_DIR:原 settings.py 中的 BASE_DIR = Path(__file__).resolve().parent.parent 得改成向上多一层——Path(__file__).resolve().parent.parent.parent,否则静态路径、数据库路径全错。
常见错误现象:ModuleNotFoundError: No module named 'myproject.settings' 或 django.core.exceptions.ImproperlyConfigured: The SECRET_KEY setting must not be empty,基本都是包结构或 BASE_DIR 错了。
dev.py 和 prod.py 怎么继承 base.py 又不覆盖关键配置
用 from .base import * 导入是可行的,但要注意:Python 的星号导入不支持后续对字典类配置(如 INSTALLED_APPS、MIDDLEWARE)的「原地修改」——你得显式叠加或替换。
推荐写法:
-
DEBUG = True或False直接赋值(覆盖) -
ALLOWED_HOSTS = ['localhost', '127.0.0.1']完全覆盖(别用+=,prod 环境若漏设会 500) -
INSTALLED_APPS += ['debug_toolbar']仅在dev.py中追加,但前提是base.py里INSTALLED_APPS是 list 类型(不是 tuple) -
DATABASES整体重写,不要试图在base.py里留空字典再更新——Django 初始化时会校验结构
容易踩的坑:prod.py 忘记设 SECRET_KEY = os.environ['SECRET_KEY'],而 base.py 里又写了默认值(比如 os.environ.get('SECRET_KEY', 'insecure')),上线后可能用开发密钥跑生产环境。
DJANGO_SETTINGS_MODULE 环境变量什么时候生效、怎么验证
这个变量必须在 django.setup() 之前就存在,也就是说:它要在 manage.py 导入任何 Django 模块前就设置好。命令行直接传参最稳:
DJANGO_SETTINGS_MODULE=myproject.settings.dev python manage.py runserver
而不是先 export DJANGO_SETTINGS_MODULE=... 再运行——某些 shell 或 IDE(比如 PyCharm)会缓存环境,导致改了不生效。
验证是否生效的方法:
- 启动时看终端输出的「Using settings」提示行
- 在 shell 中执行
python manage.py shell,然后输入from django.conf import settings; settings.SETTINGS_MODULE,返回值应为'myproject.settings.dev' - 检查
settings.DEBUG是否符合预期(比如print(settings.DEBUG))
特别注意:Gunicorn、uWSGI 启动时,--env 或 env 配置项必须显式声明该变量,不能依赖 .env 文件自动加载——Django 不读 .env,那是 django-environ 或 python-decouple 干的事。
敏感配置为什么不能写死在 prod.py 里
因为镜像构建、CI/CD 日志、版本回溯都可能泄露 prod.py。哪怕加了 .gitignore,也挡不住误提交、本地调试残留、或者运维手动上传。
正确做法是只在 prod.py 里写读取逻辑:
SECRET_KEY = os.environ['SECRET_KEY']DATABASE_URL = os.environ['DATABASE_URL']
然后通过以下任一方式注入:
- Docker:
docker run -e SECRET_KEY=xxx -e DATABASE_URL=... my-django-app - Kubernetes:
envFrom: [{secretRef: {name: django-secrets}}] - systemd service:
Environment=SECRET_KEY=...
最容易被忽略的一点:base.py 里绝不能给 SECRET_KEY 设 fallback 默认值。一旦设了 os.environ.get('SECRET_KEY', 'dev-key'),上线忘记配环境变量,Django 就静默用默认值跑——连告警都没有,安全形同虚设。
Python免费学习笔记(深入):立即使用
在学习笔记中,你将探索 Python 的核心概念和高级技巧!











