django的runserver不可用于生产环境，因其是单线程调试工具，无并发处理、无安全防护、不支持https、不服务静态文件、默认绑定本地地址且崩溃后无法自动恢复。
直接用 python manage.py runserver 上生产环境，等于把门钥匙交给路人——它压根没设计成对外服务的工具，连基础并发和安全防护都没有。
runserver 为什么不能上生产？
Django 自带的 runserver 是纯开发调试用的，不是 Web 服务器。它单线程、无进程管理、不支持 HTTPS、不做请求限流、不处理静态文件，更不会自动重启崩溃的进程。
- 启动时默认绑定
127.0.0.1:8000，外网根本访问不到 - 遇到一个耗时视图（比如生成报表），整个服务就卡住，后续请求排队等死
- 没有日志分级、无访问控制、无 header 过滤，XSS/CSRF 防御全靠 Django 中间件硬扛，压力全在 Python 层
Nginx 反向代理解决了哪些实际问题？
它不碰业务逻辑，只干三件事：接请求、分请求、甩请求。所有“不该让 Django 干”的活，它全包了。
-
/static/和/media/路径的请求，Nginx 直接读磁盘返回，完全不进 uWSGI 或 Django，省下大量 Python 解析开销 - 用
proxy_pass把/或/api/这类动态路径转发给 uWSGI，Django 只专注处理业务 - 可配置
client_max_body_size拦大文件上传、limit_req防刷接口、add_header X-Content-Type-Options nosniff增强安全头 - 哪怕 uWSGI 崩了，Nginx 还能返回 502 页面，而不是让用户看到连接超时或空白页
uWSGI/Gunicorn 和 Nginx 的分工边界在哪？
很多人混淆「谁该监听哪个端口」「谁该做 SSL 终止」，本质是没理清协议层级。
- uWSGI 默认走
uwsgi协议（二进制私有协议），必须由 Nginx 的ngx_http_uwsgi_module模块解析；Gunicorn 默认走 HTTP，Nginx 可用proxy_pass http://直连 - SSL 解密强烈建议放在 Nginx 层（即 HTTPS → Nginx → HTTP/uwsgi → Django），避免 Python 进程承担加解密 CPU 压力
- 不要让 uWSGI 或 Gunicorn 直接监听
0.0.0.0:80或:443—— 权限高、无防护、难限流，还绕过了 Nginx 的缓存和 header 控制能力
最常被忽略的一点：Nginx 的 upstream 块里如果配了多个 uWSGI 实例，但没加 ip_hash 或 session stickiness，登录态可能在不同 worker 间丢失——这不是 Django 的 bug，是反向代理层配置缺失导致的。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
