必须关闭 debug，否则 django 会在 500 页面暴露源码路径、sql、环境变量、数据库凭证等敏感信息；debug=false 仅关闭最显眼入口，仍需检查 allowed_hosts、admins、logging 和第三方调试工具。
必须关闭 DEBUG，否则 Django 会把源码路径、SQL 查询、环境变量、中间件栈、数据库凭证（若配置不当）直接渲染在 500 错误页面上——这不是“可能泄露”，而是只要触发一次未捕获异常，敏感信息就裸奔到公网。
DEBUG=True 时浏览器能看到什么
打开一个故意抛错的视图（比如 raise ValueError("test")），访问后你会看到：
- 完整 traceback，含每一层调用的绝对路径（如
/app/myproject/settings/prod.py） - 所有已加载的 settings 变量值，包括
DATABASES字典里的USER、PASSWORD（哪怕你用了环境变量，Django 仍会在 debug 页面展开字典） - HTTP 请求头、POST 数据、session 内容（如果没加密）、CSRF token 原始值
- 已注册的中间件顺序、模板加载路径、甚至
SECRET_KEY的内存地址（某些版本会显示 repr）
DEBUG=False 不等于安全，只是关掉了最显眼的漏洞入口
即使 DEBUG = False，以下情况仍会导致信息暴露：
-
ALLOWED_HOSTS为空或含通配符['*']→ 返回 400 或 500，但错误响应体里可能包含 WSGI server 的调试提示 - 没配
ADMINS+ 邮件后端 → 500 错误静默失败，你根本不知道线上崩了多久 -
LOGGING配置漏掉handlers或formatters→ 异常被吞掉，日志无记录 - 第三方库（如 django-debug-toolbar）没在 prod.py 中移除 → 仍可能注入调试面板（即使 DEBUG=False，部分插件有独立开关）
常见误以为“已关闭”的陷阱
这些写法看似关了 debug，实则无效或危险：
-
DEBUG = os.environ.get('DEBUG', 'False') == 'True'→ 环境变量缺失时默认为False，但拼写错成'false'就变成True -
DEBUG = bool(os.environ.get('DEBUG'))→DEBUG=""也会返回True（空字符串转 bool 是False？不，bool("")是False，但os.environ.get()返回None时bool(None)也是False；真正危险的是DEBUG=0或DEBUG=no被当成True） -
python -O manage.py runserver→ 只禁用assert，DEBUG=True依然让 Werkzeug 启动调试器，照样弹出交互式 traceback - 在
prod.py里只写了from .base import *没覆写DEBUG→ 继承 base.py 的DEBUG=True，启动直接报ImproperlyConfigured: DEBUG must be False in production
检查是否真关掉了的最低验证动作
部署后立刻执行这两步：
- curl -H "Host: evil.com" https://yoursite.com/ → 应返回 400 或 404，**不能是 500 + traceback**
- 运行
python manage.py check --deploy --settings=myproject.settings.prod→ 必须零 error，尤其关注security.W019（DEBUG未设为False）和security.W020（ALLOWED_HOSTS为空）
真正麻烦的不是设置本身，而是不同环境间配置继承链断裂、BASE_DIR 计算偏移、以及 SECRET_KEY 从环境变量读取失败时 fallback 到默认值——这些都会让 DEBUG=False 形同虚设。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
