部署清单¶
互联网是一个充满敌意的环境。在部署您的 Django 项目之前，您应该花一些时间审查您的设置，并牢记安全、性能和操作。
Django 包含许多 安全特性。有些是内置的，并且始终启用。其他是可选的，因为它们并不总是适用，或者因为它们对开发来说不方便。例如，强制使用 HTTPS 可能不适合所有网站，并且对于本地开发来说是不切实际的。
性能优化是另一类与便利性权衡的类别。例如，缓存在生产环境中很有用，而在本地开发环境中则不那么有用。错误报告的需求也大不相同。
以下清单包括以下设置
必须正确设置才能使 Django 提供预期的安全级别；
预计在每个环境中都会有所不同；
启用可选的安全特性；
启用性能优化；
提供错误报告。
许多这些设置都很敏感，应视为机密信息。如果您要发布项目的源代码，一种常见做法是发布适合开发的设置，并使用私有设置模块进行生产。
运行 manage.py check --deploy¶
下面描述的一些检查可以使用 check --deploy 选项自动执行。请务必根据该选项文档中所述针对您的生产设置文件运行它。
停止使用 manage.py runserver¶
runserver 命令并非设计用于生产环境。请务必切换到生产就绪的 WSGI 或 ASGI 服务器。有关一些常见选项，请参阅 WSGI 服务器 或 ASGI 服务器。
关键设置¶
SECRET_KEY¶
密钥必须是一个大的随机值，并且必须保密。
确保生产中使用的密钥在其他任何地方都没有使用，并避免将其提交到源代码控制中。这减少了攻击者获取密钥的途径数量。
不要在设置模块中硬编码密钥，而是考虑从环境变量
import os
SECRET_KEY = os.environ["SECRET_KEY"]
或从文件中加载它
with open("/etc/secret_key.txt") as f:
SECRET_KEY = f.read().strip()
如果轮换密钥，您可以使用 SECRET_KEY_FALLBACKS
import os
SECRET_KEY = os.environ["CURRENT_SECRET_KEY"]
SECRET_KEY_FALLBACKS = [
os.environ["OLD_SECRET_KEY"],
]
确保及时从 SECRET_KEY_FALLBACKS 中删除旧密钥。
DEBUG¶
您绝不能在生产环境中启用调试模式。
您肯定是在使用 DEBUG = True 开发您的项目，因为这启用了诸如在浏览器中显示完整回溯之类的便捷功能。
但是，对于生产环境，这是一个非常糟糕的主意，因为它泄露了有关您项目的许多信息：您的源代码片段、局部变量、设置、使用的库等。
特定于环境的设置¶
ALLOWED_HOSTS¶
当 DEBUG = False 时，如果没有 ALLOWED_HOSTS 的合适值，Django 根本无法工作。
此设置是保护您的网站免受某些 CSRF 攻击所必需的。如果您使用通配符，则必须自行验证 Host HTTP 标头，或以其他方式确保您不受此类攻击的影响。
您还应该配置位于 Django 前面的 Web 服务器以验证主机。它应该使用静态错误页面进行响应，或者忽略对不正确主机 的请求，而不是将请求转发到 Django。这样，您就可以避免 Django 日志中出现无意义的错误（或者如果您已配置了错误报告，则避免电子邮件中出现错误）。例如，在 nginx 上，您可以设置一个默认服务器，以便在无法识别的主机上返回“444 无响应”
server {
listen 80 default_server;
return 444;
}
CACHES¶
如果您正在使用缓存，则开发和生产环境中的连接参数可能不同。Django 默认使用每个进程的 本地内存缓存，这可能不理想。
缓存服务器通常具有弱身份验证。确保它们仅接受来自应用程序服务器的连接。
DATABASES¶
数据库连接参数在开发和生产环境中可能不同。
数据库密码非常敏感。您应该像保护 SECRET_KEY 一样保护它们。
为了最大限度地提高安全性，请确保数据库服务器仅接受来自应用程序服务器的连接。
如果您尚未为数据库设置备份，请立即设置！
STATIC_ROOT 和 STATIC_URL¶
静态文件由开发服务器自动提供服务。在生产环境中，您必须定义一个 STATIC_ROOT 目录，collectstatic 将把文件复制到该目录。
有关更多信息，请参阅 如何管理静态文件（例如图像、JavaScript、CSS）。
MEDIA_ROOT 和 MEDIA_URL¶
媒体文件由您的用户上传。它们不可信！确保您的 Web 服务器从不尝试解释它们。例如，如果用户上传了一个 .php 文件，Web 服务器不应该执行它。
现在是检查这些文件的备份策略的好时机。
HTTPS¶
任何允许用户登录的网站都应该强制执行站点范围的 HTTPS，以避免以明文形式传输访问令牌。在 Django 中，访问令牌包括登录/密码、会话 Cookie 和密码重置令牌。（如果您通过电子邮件发送密码重置令牌，则无法对其进行太多保护。）
保护用户帐户或管理员等敏感区域是不够的，因为相同的会话 Cookie 用于 HTTP 和 HTTPS。您的 Web 服务器必须将所有 HTTP 流量重定向到 HTTPS，并且仅将 HTTPS 请求传输到 Django。
设置 HTTPS 后，请启用以下设置。
性能优化¶
设置 DEBUG = False 将禁用开发中才需要的几个功能。此外，您可以调整以下设置。
会话¶
考虑使用 缓存会话 来提高性能。
如果使用数据库支持的会话，请定期 清除旧会话 以避免存储不必要的数据。
CONN_MAX_AGE¶
启用 持久数据库连接 可以带来显著的加速，尤其是在数据库连接占用了请求处理时间很大一部分的情况下。
这在网络性能有限的虚拟化主机上很有帮助。
TEMPLATES¶
启用缓存模板加载器通常可以大幅提高性能，因为它避免了每次渲染模板时都重新编译模板。当 DEBUG = False 时，缓存模板加载器会自动启用。有关更多信息，请参阅 django.template.loaders.cached.Loader。
错误报告¶
在将代码推送到生产环境之前，希望它已经足够健壮，但您无法排除意外错误。幸运的是，Django 可以捕获错误并相应地通知您。
LOGGING¶
在将您的网站投入生产环境之前，请查看您的日志记录配置，并在收到一些流量后检查它是否按预期工作。
有关日志记录的详细信息，请参阅 日志记录。
ADMINS 和 MANAGERS¶
ADMINS 将通过电子邮件收到 500 错误的通知。
MANAGERS 将收到 404 错误的通知。 IGNORABLE_404_URLS 可以帮助过滤掉虚假报告。
有关通过电子邮件进行错误报告的详细信息，请参阅 如何管理错误报告。
通过电子邮件进行错误报告的可扩展性不是很好。
在您的收件箱被报告淹没之前，请考虑使用错误监控系统（例如 Sentry）。Sentry 还可以聚合日志。
自定义默认错误视图¶
Django 包含几个 HTTP 错误代码的默认视图和模板。您可以通过在根模板目录中创建以下模板来覆盖默认模板：404.html、500.html、403.html 和 400.html。使用这些模板的 默认错误视图 应该足以满足 99% 的 Web 应用程序，但您也可以 自定义它们。
