我对这个问题的解决方案在某种程度上也是这里已经提到的一些解决方案的混合:

我保留了一个名为local_settings.py的文件，其内容为USING_LOCAL = True在dev中，USING_LOCAL = False在prod中 在settings.py中，我对该文件进行导入以获得USING_LOCAL设置

然后我将所有与环境相关的设置都基于此:

DEBUG = USING_LOCAL
if USING_LOCAL:
    # dev database settings
else:
    # prod database settings

我更喜欢这样，而不是有两个单独的settings.py文件，我需要维护，因为我可以将我的设置结构化地保存在一个文件中，而不是将它们分布在几个文件中。就像这样，当我更新一个设置时，我不会忘记在两个环境中都这样做。

当然每种方法都有它的缺点，这种方法也不例外。这里的问题是，无论何时将更改推到生产环境中，我都不能覆盖local_settings.py文件，这意味着我不能盲目地复制所有文件，但这是我可以接受的。

记住，settings.py是一个活动代码文件。假设您没有在生产中设置DEBUG(这是一个最佳实践)，您可以执行如下操作:

if DEBUG:
    STATIC_PATH = /path/to/dev/files
else:
    STATIC_PATH = /path/to/production/files

非常基本，但是理论上，您可以根据DEBUG的值或您想使用的任何其他变量或代码检查来提高任何复杂级别。

如果你愿意，可以选择维护不同的文件: 如果您正在使用git或任何其他VCS将代码从本地推送到服务器，您可以将设置文件添加到.gitignore。

这将允许您在两个地方有不同的内容而没有任何问题。所以在服务器上，你可以配置一个独立版本的settings.py，任何在本地所做的更改都不会反映在服务器上，反之亦然。

此外，它将删除settings.py文件从github也，大错误，这我已经看到许多新手做。

我将我的设置拆分如下

settings/
     |
     |- base.py
     |- dev.py
     |- prod.py  

我们有三种环境

dev 暂存 生产

现在，显然登台和生产应该有尽可能相似的环境。所以我们同时保留了prod.py。

但是在这种情况下，我必须确定正在运行的服务器是生产服务器。@T。斯通的回答帮助我写了如下支票。

from socket import gethostname, gethostbyname  
PROD_HOSTS = ["webserver1", "webserver2"]

DEBUG = False
ALLOWED_HOSTS = [gethostname(), gethostbyname(gethostname()),]


if any(host in PROD_HOSTS for host in ALLOWED_HOSTS):
    SESSION_COOKIE_SECURE = True
    CSRF_COOKIE_SECURE = True  

大多数解决方案的问题是，您要么将本地设置应用在常用设置之前，要么应用在常用设置之后。

所以不可能覆盖

特定于env的设置定义了memcached池的地址，在主设置文件中，这个值用于配置缓存后端 特定环境的设置添加或删除应用程序/中间件到默认的

同时。

一种解决方案可以使用“ini”风格的配置文件和ConfigParser类实现。它支持多个文件、延迟字符串插值、默认值和许多其他优点。 一旦加载了许多文件，就可以加载更多的文件，它们的值将覆盖之前的文件(如果有的话)。

您可以加载一个或多个配置文件，这取决于计算机地址、环境变量，甚至是先前加载的配置文件中的值。然后只需使用解析后的值填充设置。

我成功使用的一个策略是:

Load a default defaults.ini file Check the machine name, and load all files which matched the reversed FQDN, from the shortest match to the longest match (so, I loaded net.ini, then net.domain.ini, then net.domain.webserver01.ini, each one possibly overriding values of the previous). This account also for developers' machines, so each one could set up its preferred database driver, etc. for local development Check if there is a "cluster name" declared, and in that case load cluster.cluster_name.ini, which can define things like database and cache IPs

举个例子，你可以定义一个“子域”值per-env，然后在默认设置中使用(hostname: %(subdomain).whatever.net)来定义django工作所需的所有必要的主机名和cookie。

这是我能得到的DRY，大多数(现有的)文件只有3或4个设置。除此之外，我还必须管理客户配置，所以存在一组额外的配置文件(包括数据库名称、用户和密码、分配的子域等)，每个客户一个或多个。

您可以根据需要将其扩展到低或高，只需在配置文件中放入您想要在每个环境中配置的键，一旦需要新的配置，将先前的值放在默认配置中，并在必要时覆盖它。

该系统已被证明是可靠的，并与版本控制工作良好。它已经被使用很长时间来管理两个独立的应用程序集群(每台机器上有15个或更多的django站点实例)，有超过50个客户，集群的大小和成员会根据系统管理员的情绪而变化……

对于我的大多数项目，我使用以下模式:

创建settings_base.py，其中存储所有环境的通用设置 每当我需要使用具有特定要求的新环境时，我都会创建新的设置文件(例如。Settings_local.py)，它继承settings_base.py的内容，并覆盖/添加适当的设置变量(从settings_base import *)

(要使用自定义设置文件运行manage.py，只需使用——settings命令option: manage.py <命令>——settings=settings_you_wish_to_use.py)