Django项目部署优化：从WSGI配置到静态资源缓存的生产环境调优

Shen HongXue 2026-09-18 07:20

很多程序员都遇到过这种情况：本地开发一切正常，代码一上生产，网页加载慢得像蜗牛，有时候还会出现“服务器错误”。问题往往不在业务代码，而是部署环境没有做好优化。今天就从两个关键环节讲起：WSGI配置和静态资源缓存。咱们用一套纯Python/Django的技术栈来演示，不额外引入Nginx，这样你只要懂Python也能照着做。

一、搞清楚我们的应用到底卡在哪

我们先把思路理清。Django项目跑在开发阶段用的是自带的开发服务器，它非常方便，改完代码自动重载，还能显示调试信息。但这个服务器的设计目标是给开发者调试用的，不是给真实用户用的。它只能处理少量请求，扛不住并发，也不会优化静态文件。如果你直接拿它当生产服务器，那网站卡顿就是必然的。

所以我们要做的第一件事，是明确卡顿的源头在哪里。通常有三个地方：一是Web服务器处理请求的能力不够，二是数据库查询太慢，三是静态文件（CSS、JS、图片等）没有做缓存。本文重点讲第一个和第三个。

在动手改代码之前，可以用Django自带的安全检查命令，看看项目有没有明显的配置问题。在项目根目录运行下面的命令，技术栈是Python/Django：

python manage.py check --deploy

这个命令会列出一些生产环境警告，比如DEBUG没关、ALLOWED_HOSTS没设置等。虽然它不是性能检测工具，但能帮我们排除掉很多低级错误。

1.1 开发服务器不能用于生产

很多人对“开发服务器”有误解，认为它就是“自己跑的服务器”。其实Django官方的runserver只是基于Python内置的WSGI服务器实现，功能很基础。它不支持高并发，处理请求时是单进程的，而且会加载很多调试用的中间件，拖慢速度。更重要的是，它没有针对静态文件做任何缓存策略。

所以生产部署需要一个专门的WSGI服务器，比如Gunicorn、uWSGI。它们负责把HTTP请求转换成Django能理解的WSGI协议，然后交给你的应用处理。

1.2 优化前先做一次体检

正式调优之前，最好先观察当前应用的响应时间。可以用一个简单的Python脚本模拟请求，看看从发出请求到拿到响应要多久。下面是一个用requests库写的探针脚本，技术栈是Python/Django：

# 探针脚本：查看一个页面的响应时间和响应头
import requests
import time

# 把地址换成你的生产环境地址
url = "https://yourdomain.com"

start = time.time()
resp = requests.get(url, timeout=10)
cost = time.time() - start

print(f"状态码: {resp.status_code}")
print(f"总耗时: {cost * 1000:.2f} 毫秒")
print(f"响应头里的Server: {resp.headers.get('Server')}")
print(f"Cache-Control: {resp.headers.get('Cache-Control')}")

如果耗时几十毫秒甚至上百毫秒，说明还有很多优化空间。注意，这个脚本只是帮你建立“数据直觉”，实际压测还是需要更专业的工具，但那超出了本文范围。

二、WSGI配置：让Django跑在高性能服务器上

WSGI（Web Server Gateway Interface）是Python Web应用的通用接口标准。Django本身遵循这个标准，所以任何支持WSGI的服务器都可以跑Django项目。把WSGI配置好，是生产环境调优的第一步。

2.1 为什么选择Gunicorn

Gunicorn是一个用Python写的WSGI服务器，在很多Linux发行版上都能直接用。它的优点是简单、稳定，不需要写复杂的配置文件。相比uWSGI，Gunicorn更容易上手，社区也很大。我们用Gunicorn作为示例，技术栈依然是Python/Django。

2.2 编写生产用WSGI配置

Django项目里有一个wsgi.py文件，默认内容非常简单。在大多数情况下，这个文件不需要大改，但你可以在加载时指定生产环境使用的配置模块，而不是在启动命令里反复改参数。下面是优化后的wsgi.py，技术栈为Python/Django：

# myproject/wsgi.py
import os
from django.core.wsgi import get_wsgi_application

# 设置默认的环境变量，优先使用生产配置
# 系统环境变量里的DJANGO_SETTINGS_MODULE优先级更高
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myproject.settings.production')

application = get_wsgi_application()

这里的setdefault表示如果环境变量已经存在，就不覆盖。这样本地开发时，你还可以在启动命令里临时指定开发配置。

2.3 用Gunicorn启动项目

安装Gunicorn很简单，技术栈是Python/Django：

pip install gunicorn

启动Django项目的命令如下。因为我们要保证示例是单一技术栈，启动时用python -m gunicorn，这样它就是Python生态里的一个模块，不会和系统级命令混在一起：

python -m gunicorn myproject.wsgi:application \
  --bind 0.0.0.0:8000 \
  --workers 3 \
  --threads 2 \
  --timeout 60 \
  --access-logfile -

解释一下这些参数：

bind指定监听的IP和端口。0.0.0.0表示公网可访问，线上别暴露8000到外部，最好通过防火墙或反向代理。
workers是进程数，一般设为CPU核心数加1。
threads是每个进程里的线程数，适合处理IO密集操作。
timeout是超时时间，如果某个请求超过60秒没完成，Gunicorn会自动杀掉它，防止请求堆积。
access-logfile -表示把访问日志输出到控制台，方便你调试。

2.4 进程数怎么调

很多初学者喜欢把workers设得特别大，以为越大越好。但实际上，每个worker都是独立的Python进程，需要占用内存；同时因为Python GIL的存在，多线程对CPU密集任务帮助有限。这里给一个简单公式：

如果你的服务器是2个CPU核心，建议workers设为3，threads设为2。
如果业务主要是IO操作（比如大量读数据库），可以适当调高threads，但不超过8。
如果业务涉及密集计算（比如图像处理），最好多开workers，少开threads。

在实际部署时，先用压力测试工具观察CPU和内存，找到最优组合。不要盲目抄参数。

三、把配置按环境拆开

在生产环境里，我们会遇到很多和开发环境不一样的要求。比如数据库密码、静态文件路径、安全设置等。如果全部塞进一个settings.py里，很容易出问题。所以通常会将配置拆成多个文件，放到一个settings包下面。

3.1 拆分配置文件

我们创建一包目录settings/，里面放base.py、development.py、production.py。在base.py里放公共配置，比如INSTALLED_APPS、MIDDLEWARE基础部分。然后在开发和生产配置里分别导入。

下面示例展示生产配置里和部署优化相关的几个关键项，技术栈是Python/Django：

# myproject/settings/production.py
from .base import *

# 关闭调试模式，这是生产环境最基础的一步
DEBUG = False

# 只允许自己的域名访问，防止Host头攻击
ALLOWED_HOSTS = ['www.yourdomain.com', 'yourdomain.com']

# 数据库连接池相关参数（这里用Django内置的CONN_MAX_AGE）
# 可以在一次请求生命周期内复用数据库连接，减少连接开销
CONN_MAX_AGE = 60

# 安全相关设置
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
SECURE_SSL_REDIRECT = True
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True

注意，SECURE_SSL_REDIRECT和SECURE_PROXY_SSL_HEADER需要搭配反向代理使用，如果你直接在云服务器上用HTTP访问，别开这个强制跳转。

3.2 收集静态文件

Django默认不会自动收集每个App里的静态文件到指定目录。所以执行下面这条Python/Django命令：

python manage.py collectstatic --noinput

这条命令会从各个App和项目目录里找到静态文件，复制到STATIC_ROOT指定的目录。只有执行完这一步，生产环境里的Web服务器才能直接提供这些文件。

四、静态资源缓存：让加载速度快一倍

静态文件（CSS、JS、图片）往往占了网站总请求量的百分之七八十。如果这些文件没做缓存，用户每次打开页面都要重新下载，体验会非常差。做好静态资源缓存，是性价比极高的一步。

4.1 用WhiteNoise代替Nginx？

传统方案是让Nginx直接服务静态文件，并设置缓存头。但是为了保持本文技术栈的统一，我们推荐一个更好的Python库：WhiteNoise。它能在不高不低地提供静态文件服务的同时，自动设置缓存头，并且可以无缝嵌入Django。对于中小型项目，WhiteNoise完全够用；就算以后要上CDN，WhiteNoise也可以作为回源。

4.2 安装并配置WhiteNoise

先安装，技术栈是Python/Django：

pip install whitenoise

然后在生产配置的MIDDLEWARE里加上WhiteNoise中间件。注意，它要放在SecurityMiddleware之后，因为安全头需要首先处理。配置如下，技术栈是Python/Django：

# myproject/settings/production.py
from .base import *

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'whitenoise.middleware.WhiteNoiseMiddleware',  # 让Django自己提供静态文件
    # 其他中间件...
]

# 静态文件目录
STATIC_ROOT = BASE_DIR / 'staticfiles'
STATIC_URL = '/static/'

# 使用WhiteNoise的压缩和缓存版本后端
STORAGES = {
    "default": {
        "BACKEND": "django.core.files.storage.FileSystemStorage",
    },
    "staticfiles": {
        "BACKEND": "whitenoise.storage.CompressedManifestStaticFilesStorage",
    },
}

如果你用的是Django 4.2以下版本，需要写成STATICFILES_STORAGE，不过那已经是旧用法。这里以新版为准。

4.3 自动缓存机制

设置完以后，WhiteNoise会给带哈希值的静态文件（比如style.55f4f2.css）自动加上这样的响应头：

Cache-Control: max-age=31536000, immutable

max-age=31536000表示让浏览器缓存一年，immutable表示这个文件内容不会变了，浏览器可以直接用本地的版本，连请求都不发。这就大大减少了静态文件请求。

当你的源文件（比如style.css）变化时，重新运行collectstatic生成的哈希也会变化，生成新的文件名。旧的引用失效，浏览器自然会去下载新文件。这个机制非常聪明——文件名即版本号，无需手动清理缓存。

你也可以用Python脚本验证一下缓存头是否生效。下面是一个简单的检查脚本，技术栈是Python/Django：

import requests

# 假设你的静态文件名带哈希，可以用你实际的文件名替换
url = "https://yourdomain.com/static/css/style.55f4f2.css"
resp = requests.get(url)
print("Cache-Control:", resp.headers.get('Cache-Control'))
print("Expires:", resp.headers.get('Expires'))

正常情况下，你会看到输出结果是像Cache-Control: max-age=31536000, immutable这样的内容。如果看到no-cache或没有Cache-Control，说明配置没生效，可以检查中间件顺序。

4.4 缓存周期怎么选

对于带哈希的文件，一年甚至十年都没问题，因为文件名变了就会重新下载。但对于一些不改变文件名的资源（比如用户上传的图片），不要把缓存时间设得太长。否则改完图片用户看到的还是旧图。WhiteNoise默认对这类资源不设置超长缓存，你也可以通过自定义WhiteNoise子类来调节，不过一般默认就够用了。

五、数据库与内存的辅助优化

除了WSGI和静态资源，生产环境调优还绕不开数据库和内存。这里简单提两个点，不做深挖。

首先，在settings.py里设置CONN_MAX_AGE，让数据库连接在请求之间复用，可以减少建立连接的开销。上面的production.py里已经设置了60秒，这个值可以根据数据库负载调整。

其次，可以考虑给Django加上缓存。比如用Python的django.core.cache配合内存缓存，对一些频繁查询的结果做缓存。配置非常简单，技术栈是Python/Django：

# myproject/settings/production.py
CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
        'LOCATION': 'production-cache',
        'TIMEOUT': 300,
    }
}

内存缓存适合单机小项目，如果以后需要多台服务器共享缓存，再考虑数据库缓存或Redis。这里为了保持单一技术栈，就不展开Redis了。

六、应用场景、优缺点与注意事项

6.1 应用场景

这套优化方案特别适合中小型Django项目，例如企业官网、内部管理系统、API服务等。如果项目访问量不大，但有追求较好的响应速度，用“Gunicorn + WhiteNoise”就足够了。对于大型项目，通常还会加上Nginx和CDN，但那是架构层面的故事，不是本文的主题。

6.2 技术优缺点

Gunicorn的优点很明显：部署简单、配置灵活、兼容性好；缺点是它更适合常规Web服务，如果有长连接或WebSocket需求，就需要额外支持。

WhiteNoise最大的优点是纯Python，不需要配置独立的Nginx，学习成本低；缺点是它的性能不如Nginx这样的C语言级静态文件服务器，当静态文件特别多、请求特别大时，可能成为瓶颈。

6.3 注意事项

第一，DEBUG必须为False，否则Django会暴露完整的错误堆栈给用户，非常危险。

第二，每次发布新版本，如果有静态文件改动，一定记得重新执行collectstatic。

第三，不要为了让代码看起来“专业”而堆砌过大的worker数量。要根据服务器实际资源来配，不然内存很快被吃光。

第四，定时重启Gunicorn可以避免内存泄漏慢慢积累。虽然这不是必须，但一个简单的定时任务就能让服务长期稳定。

七、文章总结

生产环境调优听起来很深奥，其实核心就是三件事：用高性能WSGI服务器替代开发服务器、拆分配置并关闭调试模式、给静态文件做长期缓存。本文用Gunicorn + WhiteNoise这套纯Python技术栈，完整展示了这几个步骤。你不需要一次全部做完，可以先从关闭DEBUG开始，再逐步加上WhiteNoise，最后再调整Gunicorn的进程数。每次改完都做一次小规模验证，比如用前面的Python探针脚本看响应时间。优化是一个不断测试、不断调整的过程。

最后再强调一下：本地跑得动真不算本事，生产环境扛得住、返回快，才是真的好。

围绕“Django项目部署优化：从WSGI配置到静态资源缓存的生产环境调优”参与讨论

0 条

Django项目部署优化：从WSGI配置到静态资源缓存的生产环境调优

一、搞清楚我们的应用到底卡在哪

1.1 开发服务器不能用于生产

1.2 优化前先做一次体检

二、WSGI配置：让Django跑在高性能服务器上

2.1 为什么选择Gunicorn

2.2 编写生产用WSGI配置

2.3 用Gunicorn启动项目

2.4 进程数怎么调

三、把配置按环境拆开

3.1 拆分配置文件

3.2 收集静态文件

四、静态资源缓存：让加载速度快一倍

4.1 用WhiteNoise代替Nginx？

4.2 安装并配置WhiteNoise

4.3 自动缓存机制

4.4 缓存周期怎么选

五、数据库与内存的辅助优化

六、应用场景、优缺点与注意事项

6.1 应用场景

6.2 技术优缺点

6.3 注意事项

七、文章总结

评论

关联文章

AI助手

一、搞清楚我们的应用到底卡在哪

1.1 开发服务器不能用于生产

1.2 优化前先做一次体检

二、WSGI配置：让Django跑在高性能服务器上

2.1 为什么选择Gunicorn

2.2 编写生产用WSGI配置

2.3 用Gunicorn启动项目

2.4 进程数怎么调

三、把配置按环境拆开

3.1 拆分配置文件

3.2 收集静态文件

四、静态资源缓存：让加载速度快一倍

4.1 用WhiteNoise代替Nginx？

4.2 安装并配置WhiteNoise

4.3 自动缓存机制

4.4 缓存周期怎么选

五、数据库与内存的辅助优化

六、应用场景、优缺点与注意事项

6.1 应用场景

6.2 技术优缺点

6.3 注意事项

七、文章总结

同分类面试题

关联文章

AI助手