在Linux实例部署Django项目时，为何需使用Gunicorn而非runserver？

好问题！很多刚把Django项目部署到云服务器（比如你用的Google Compute Engine）的开发者都会有这个疑惑——毕竟python3 manage.py runserver 0.0.0.0:8080在本地跑的顺顺当当，到了生产环境为啥还要额外装Gunicorn这类WSGI服务器？咱们拆解开说：

• runserver本质是个开发调试工具，不是生产级服务器
  Django自带的runserver是专门给开发者本地调试用的，它的设计目标是方便快速预览代码变化，而不是应对真实的用户流量。它默认是单线程的，同时来了几个请求就得排队处理，并发量稍微上去就直接卡爆；而且它的代码没有做性能优化，错误信息会直接暴露给请求者，很容易泄露项目的敏感细节（比如数据库路径、代码结构），完全不符合生产环境的安全要求。

• WSGI是Python Web应用的标准通信协议
  简单说，WSGI就是一套规则，定义了Web服务器（比如Gunicorn）和Python Web应用（比如Django）之间怎么传递请求和响应。Django本身是遵循WSGI规范的应用，但它自己没法直接处理客户端的HTTP请求——这时候就需要Gunicorn来当“中间人”：它负责接收来自客户端（或者反向代理比如Nginx）的HTTP请求，把它转换成Django能理解的WSGI格式，传给Django处理，再把Django返回的响应转成HTTP格式发回给客户端。

• Gunicorn能提供生产级的稳定性与性能
  Gunicorn支持多进程、多线程模式，可以同时处理大量并发请求，性能比runserver强几个量级；它还支持守护进程运行，就算意外崩溃也能自动重启，保证服务不中断；另外它的日志管理更完善，能帮你记录请求详情、错误信息，方便排查生产环境的问题。而且它能和Nginx这类反向代理服务器完美配合，让Nginx来处理静态文件、SSL证书、负载均衡这些Gunicorn不擅长的事情，进一步提升服务的稳定性和安全性。

• 安全层面的必要性
  runserver没有任何安全加固措施，比如它不会限制请求的大小，很容易被恶意请求搞垮；也没法处理HTTPS这类加密通信。而Gunicorn配合Nginx之后，你可以轻松配置SSL、设置请求过滤、限制访问频率，大幅降低被攻击的风险。

总结一下：runserver是给你本地写代码时快速看效果用的，而Gunicorn是让你的Django应用在生产环境里稳定、安全、高效运行的必备工具。

内容的提问来源于stack exchange，提问作者Nader