Django:STATIC_*和MEDIA_*完全相同，但应用程序仍在生产中运行

我目前正在开发Django 1.3应用程序，其中

MEDIA\u ROOT

和

STATIC\u ROOT

都是相同的，

MEDIA\u URL

和

STATIC\u URL

都是相同的

这（以某种方式）在生产服务器上运行，但在本地调用

manage.py runserver

时，我会得到一个

配置不正确的

异常，并且只能在覆盖设置时运行应用程序，以便

媒体*

不同于

静态*

（

DEBUG=False

仅给出500）。这是我期望发生的（），因此我不明白他们如何让它在生产中工作

---

应用程序的原始开发人员已经离开了，所以我不能问任何问题，因为他们是如何设法让它工作的。有没有一种已知的方法可以绕过Django的静态文件和媒体文件分离？

这不是一个很好的答案，因为它非常具体，但答案是他们永远不会使用

DEBUG=True

运行应用程序（runserver将使用

DEBUG=False

和不正确的

media.*

和

static.*

设置愉快地运行）。没有银弹，应用程序似乎是使用mod_wsgi创建的错误日志进行调试的（没有日志记录）。我假设这也是开发环境的设置方式

该应用程序还值得注意的是，它在运行时不在

PYTHONPATH

上，并且其所有应用程序都位于文件系统另一部分的单独文件夹中。这是在将新应用程序添加到包含

manage.py

的文件夹时发现的，并且新应用程序存在导入错误。我认为这是为了让多个django安装可以使用同一组应用程序

---

感谢Yuji的帮助。

您能确认生产设置吗？进入生产环境，打开manage.py shell，并从django.conf导入设置中拉出

；打印（settings.STATIC\u URL、settings.MEDIA\u URL）

——也许某些代码在检测到环境后正在动态修改设置？谁知道。。。还可以在生产机器上尝试

manage.py runserver

——可能有人侵入了django安装。祝你好运感谢Yuji的评论，我尝试了以上所有内容，它非常高兴地报告了相同的STATIC*和MEDIA*，DEBUG=False。我下载了django安装和PyPi的django（相同版本）并对它们进行了区分，它们是相同的。答案不会太遥远：）这意味着runserver在远程上会像在本地上一样失败？runserver在远程上工作正常（与本地不同），如果我运行manage.py shell并手动调用

django.contrib.staticfiles.utils.check_settings（）

它会引发不正确的配置，但在运行

runserver

时，似乎没有失败/被调用。