runserver 的单线程模型

很多人在学习 Django 时都会先用 python manage.py runserver 启动开发服务器，因为它简单、自动重载、还能直接看到调试信息。但等到项目需要上线时，这种用法就埋下了隐患。Django 的 manage.py runserver 本质上是一个单进程、单线程的 WSGI 服务器，默认情况下它只能串行处理请求。当同时有多个客户端发起请求时，未处理的请求会进入等待队列，导致响应延迟累积。在生产环境中，即使只有几十个并发请求，也可能造成请求超时甚至服务完全阻塞。你可以在开发过程中通过同时打开两个浏览器标签页并发送耗时请求来验证这一行为——第二个请求会在第一个完成之前一直处于挂起状态。这个特性在开发调试时问题不大，但一旦暴露给真实用户，响应速度会迅速恶化。

调试信息与安全风险

除了并发瓶颈，runserver 另一个不适合生产的原因是它默认开启了 DEBUG 模式，并且会在报错时输出完整的 Traceback。runserver 在开发环境下非常便利，因为它会自动重载代码并输出详细的调试信息。但在生产环境中，这些特性反而成为风险：自动重载会频繁重启进程导致服务中断，而调试模式暴露的 Traceback 信息可能泄露数据库密码、文件路径等敏感内容。即便在关闭 DEBUG 的情况下，单线程模型依然会让你的服务在面对突发流量时迅速崩溃。记住，runserver 的设计目标从来就不是处理生产负载，尝试用它上线相当于拿玩具刀上战场。

正确的部署架构

既然 runserver 不适合生产，那么生产环境应该用什么？部署生产环境时应使用专业的 WSGI 服务器，例如 Gunicorn 或 uWSGI，并配置合理的 worker 数量和进程模型。通常的做法是在前端放置 Nginx 或 Apache 作为反向代理，负责静态文件服务和负载均衡，后端通过 Gunicorn 启动多个 worker 进程处理 Django 应用。一个典型的启动命令可能是：gunicorn myproject.wsgi:application --workers=4 --bind=0.0.0.0:8000。这样的架构才能提供可靠的并发处理能力。workers 数量一般建议设置为 CPU 核心数的 2 倍加 1，但需要结合具体环境进行压测调整。Nginx 配置中需要将动态请求 proxy_pass 到 Gunicorn 监听的地址，静态文件则直接由 Nginx 处理，避免把静态请求压到 Django 进程上。

容易忽略的检查点

从 runserver 切换到 Gunicorn 后，有几个地方容易踩坑。第一，务必确认 DEBUG = False 且 ALLOWED_HOSTS 配置正确，否则 Gunicorn 启动后可能返回 400 错误。第二，如果使用 runserver 0.0.0.0:80 绑定低权限端口，需要以 root 用户运行，这本身会带来额外的安全风险；改用 Nginx 反向代理后，可以让 Nginx 以 root 绑定 80 端口，Gunicorn 以普通用户监听更高的端口（如 8000）。第三，检查静态文件收集是否执行了 python manage.py collectstatic，并且 Nginx 的静态文件路径是否正确指向收集目录。第四，使用进程管理工具（如 Supervisor 或 systemd）来确保 Gunicorn 在意外退出后自动重启，否则一次崩溃就会导致服务长时间不可用。

如果项目已经上线，可以通过查看日志确认是否仍有请求被 runserver 处理：检查进程列表，如果看到 python manage.py runserver 进程，说明部署没有切换成功。另外，尝试同时发送两个并发请求，观察第二个请求是否被阻塞，这是快速判断是否仍在使用单线程服务器的方法。总之，先理解 runserver 的边界，再选择适合生产压力的 WSGI 服务器，才能让 Django 应用稳定对外服务。