django的runserver仅用于开发调试，不可用于生产环境。它是单进程、无超时、debug=true，默认暴露敏感配置，不支持并发、静态文件服务、unix socket及自动重启，安全性与稳定性均不达标。
Django 自带的 runserver 根本不是生产服务器，它连“能用”都算不上，只是个调试工具。
为什么 runserver 不能上生产
Django 的 runserver 是单进程、无超时、默认 DEBUG=True 的开发专用服务。它会把整个 Python 进程堆栈、环境变量、数据库配置路径全暴露在错误页里——只要触发一个 500，攻击者就能看到你 settings.py 里写的 DATABASE_URL。
- 1 个慢请求（比如上传大文件或调外部 API 卡住）会阻塞所有后续请求
- 崩溃后进程直接退出，没自动重启机制，服务就断了
- 不处理静态文件，也不支持 Unix socket，没法和 nginx 安全配合
- 没有连接池、请求限速、资源隔离等任何生产级能力
gunicorn 解决了哪些核心问题
gunicorn 是 WSGI 协议的实现，它的角色就是“稳稳地把你的 Django 应用接进真实网络”。它不改你一行业务代码，只负责调度、隔离、兜底：
- 用
--workers启动多个独立进程，一个挂了不影响其他请求 - 通过
--timeout强制中断卡死的请求，避免 worker 被长期占用 - 支持
unix:/tmp/myproject.sock绑定，让 nginx 可以本地高效通信，且外部无法直连 - 主进程（
master）监控所有 worker，崩溃后秒级拉起新进程，用户几乎无感
为什么必须配 nginx，不能只用 gunicorn
直接跑 gunicorn --bind 0.0.0.0:8000 myproject.wsgi:application，等于把 Gunicorn 当成裸奔的 Web 服务器用：
- 绕过了 nginx，丢失 SSL 终止、静态文件缓存、
client_max_body_size控制等关键能力 - TCP socket 比 Unix socket 多一层网络协议栈，性能差，还可能被扫描器直接打到应用层
- 没配 systemd 或守护进程，机器重启后服务就消失了
- 日志没分离，
gunicorn的访问日志和错误日志混在一起，出问题难排查
真正麻烦的不是启动命令本身
而是权限、路径、用户上下文这三处细节：socket 文件属主不对、ALLOWED_HOSTS 漏了 IP、collectstatic 输出目录和 nginx alias 不一致——这些地方一错，502 Bad Gateway 或 404 就立刻出现，但错误信息往往藏在 nginx error log 里，而不是 Django 或 gunicorn 日志中。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
