wsgi不支持长连接，必须用asgi协议栈；gunicorn是wsgi服务器，无法解析asgi的scope和事件循环，故不能真正运行websocket；uvicorn原生支持asgi，部署需配合nginx正确透传upgrade头，并确保django channels路由与异步消费者配置正确。
WSGI 本身不支持长连接，强行配置只会失败或退化为轮询；真要支持长连接（如 WebSocket、SSE、HTTP/2 流式响应），必须用 ASGI 协议栈，且服务器、框架、部署链路三者都要对齐。
为什么 Gunicorn 无法真正跑通 WebSocket
很多人试过把 Django Channels 或 FastAPI 的 asgi.py 丢进 Gunicorn 启动，结果 WebSocket 连接立刻断开或报 502 Bad Gateway。这是因为 Gunicorn 是 WSGI 服务器，它只理解 environ + start_response 的同步调用模型，完全无法解析 ASGI 的 scope 和 receive/send 事件循环。即使加了 --worker-class eventlet，也只是模拟协程，并未实现 ASGI 规范要求的多消息生命周期——它仍然按“一次请求-一次响应”收发，根本无法维持连接状态。
Uvicorn 是当前最稳妥的 ASGI 服务器选择
Uvicorn 原生实现 ASGI 协议，底层用 uvloop 替代默认 asyncio 事件循环，性能和稳定性都经过大规模生产验证。部署时注意三点：
- 不要直接暴露
Uvicorn给公网，它不是反向代理，缺乏连接限速、SSL 终止、静态文件缓存等能力 - 启动命令里必须指定
--host 127.0.0.1（而非0.0.0.0），避免被外部直连 - 若需多进程，用
--workers N，但注意每个 worker 都会独立运行一个事件循环，WebSocket连接无法跨 worker 共享状态，需搭配 Redis 或其他后端做 session 广播
示例启动命令：uvicorn myapp.asgi:application --host 127.0.0.1 --port 8000 --workers 4
Nginx 必须正确转发 Upgrade 请求
哪怕后端用了 Uvicorn，如果 Nginx 配置没改，WebSocket 依然会降级成 HTTP。关键在于让 Nginx 识别并透传 Upgrade 头：
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
- 必须显式设置
proxy_http_version 1.1 - 必须透传
Connection和Upgrade请求头：proxy_set_header Connection "upgrade"、proxy_set_header Upgrade $http_upgrade -
proxy_pass地址末尾不能带/（否则路径重写可能出错）
漏掉任意一项，浏览器发起 ws:// 连接时，Nginx 就会返回 400 Bad Request 或静默关闭连接。
Django Channels 的 asgi.py 不等于“自动支持 WebSocket”
很多 Django 项目以为只要生成了 asgi.py、装了 daphne，就万事大吉。其实这只是第一步。真正要让 WebSocket 可用，还必须：
- 在
routing.py中明确定义URLRouter或ProtocolTypeRouter，把websocket路径映射到具体 consumer -
Consumer类必须继承AsyncWebsocketConsumer（不是WebsocketConsumer），否则会阻塞事件循环 - 所有耗时操作（如数据库查询、HTTP 调用）必须用
async_to_sync包裹，或直接使用异步驱动（如aiosqlite、httpx.AsyncClient）
否则，哪怕连接建立成功，一执行业务逻辑就会卡死整个 worker。
ASGI 不是开关，而是整条链路的协议契约。从框架路由、服务器选型，到反向代理配置、客户端连接方式，任何一环用 WSGI 思维去套，都会在长连接场景下当场失效。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
