Django2.2开启settings.py中DEBUG为True时报500错误的求助

核心硬伤排查 #

• 生产环境数据库配置块的位置完全错误：你把if os.environ.get('ENV') == 'PRODUCTION'这段更新逻辑放在了整个settings.py的最开头，早于BASE_DIR、DATABASES等所有基础配置的定义。当你在带有ENV=PRODUCTION变量的部署环境上将DEBUG切为True时，解释器从上到下执行到这段代码时，DATABASES变量根本还没完成初始化，直接触发NameError，最终被WSGI层捕获返回500。
• 你之前DEBUG=False时运行正常，本质是这段代码原本的位置在DATABASES定义之后，调整DEBUG参数时误将代码块剪切到了文件头部，或是旧运行时的配置缓存刚好避开了这个未定义变量的触发点。

中间件配置冲突点 #

• 你将whitenoise.middleware.WhiteNoiseMiddleware放在了中间件栈的最顶部，位置早于SessionMiddleware、CommonMiddleware。DEBUG=True模式下，Django内置开发服务器会自动开启本地静态文件服务逻辑，此时两个静态文件处理链路会出现请求抢占：WhiteNoise会优先拦截请求，但DEBUG模式下的路径校验规则和生产模式不一致，一旦校验不通过就会抛异常触发500。
• DEBUG=False时，Django会关闭内置的静态文件服务，所有静态请求统一交给WhiteNoise处理，流程无冲突。这也能解释你执行collectstatic无异常、生产模式全功能正常的现象——collectstatic是独立的静态文件收集流程，不依赖运行时的中间件加载逻辑，自然不受配置冲突的影响。

落地修复步骤 #

1. 调整代码块位置：把生产环境数据库更新的逻辑，移动到settings.py中DATABASES字典定义完成之后，保证执行更新操作时，DATABASES已经是包含default键的初始化完成的字典。
2. 修正MIDDLEWARE的顺序，避免静态文件链路冲突，推荐的中间件排序为：
   • django.middleware.security.SecurityMiddleware
   • django.contrib.sessions.middleware.SessionMiddleware
   • django.middleware.common.CommonMiddleware
   • whitenoise.middleware.WhiteNoiseMiddleware
   • 后续的CSRF、Auth、Message类中间件保持原有顺序不变
3. 补全django_heroku的初始化逻辑：你当前只导入了django_heroku但没有在settings.py的末尾调用配置函数，导致DEBUG模式下的运行时配置加载不全。需要在文件最后补充执行：
   django_heroku.settings(locals())
4. 临时排查验证：删掉项目内所有__pycache__缓存文件夹后重启服务，DEBUG=True模式下本就应该展示完整的报错堆栈，此时看到的真实错误信息可以直接帮你定位剩余的配置问题。

补充说明：DEBUG=True时正常会展示带完整堆栈的调试错误页，你现在遇到500，本质是异常发生在settings模块加载的最早期阶段，早于Django错误处理中间件的初始化，根本走不到调试页面的渲染流程。

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