Django 4.2 原生不支持 WebSocket，必须通过 Channels + ASGI 实现；开发时 runserver 的“伪支持”仅限握手，路由、consumer 或配置任一错误均导致静默失败，且 CONN_MAX_AGE 必须设为 0。
Django 4.2 原生不支持 WebSocket，因为它是同步 HTTP 框架，而 WebSocket 是长连接、异步、双向协议。直接用 runserver 访问 ws:// 地址一定会返回 404 或 502（尤其加了 Nginx 反代后）。必须用 Channels + ASGI 才能跑通，且配置错一个环节就卡死。
为什么 runserver 有时“好像能连上” WebSocket
Channels 4.0+（对应 Django 4.2）在开发模式下对 runserver 做了兼容：它会悄悄把 WebSocket 升级请求转给内置的异步处理层。但这只是开发便利，不是架构改变——背后仍是 ProtocolTypeRouter 分发，且不支持并发连接测试、无健康检查、无法模拟真实负载。
- 现象：前端
new WebSocket('ws://localhost:8000/ws/chat/')能 open，但发消息没响应、consumer 不触发、日志静默 - 原因：路由没配对（
asgi.py里漏了URLRouter）、consumer 类型写错（比如该用AsyncWebsocketConsumer却写了同步版）、路径末尾多加了/导致匹配失败 - 验证方法：启动时看终端输出是否有
WebSocket connect日志；用curl -i -N -H "Upgrade: websocket" http://localhost:8000/ws/chat/手动触发握手，观察是否返回101 Switching Protocols
ASGI 配置和 consumer 编写最容易漏的三处
Channels 的核心是「协议分发 → 路由 → consumer」三层，任一环断开，WebSocket 就进不来。
-
settings.py中INSTALLED_APPS必须把'channels'放在最顶部，否则中间件加载顺序错乱，导致认证或 session 不生效 -
asgi.py必须是 Channels 生成的版本，含ProtocolTypeRouter，不能沿用旧项目里的 WSGI 改写体；确认里面有类似'websocket': URLRouter([...])的分支 - consumer 类必须继承
AsyncWebsocketConsumer（Django 4.2 默认要求异步），且方法名严格为connect、disconnect、receive；少一个async关键字或拼错函数名，整个连接就静默失败
CONN_MAX_AGE 和数据库长连接在 ASGI 下要禁用
ASGI 服务器（如 Uvicorn、Daphne）是多 worker 多协程模型，而 Django 的 CONN_MAX_AGE 是基于线程本地存储（threading.local）设计的。在协程环境下，连接复用逻辑失效，还可能引发连接泄漏或 OperationalError: server closed the connection unexpectedly。
立即学习“Python免费学习笔记（深入）”；
- 生产部署时，必须将数据库配置中的
CONN_MAX_AGE设为0（显式关闭），改用数据库原生连接池：MySQL 推荐mysql-connector-python自带池，PostgreSQL 强烈搭配pgBouncer - 开发阶段更不能开
CONN_MAX_AGE：Django 的runserver每次请求起新线程，连接根本复用不了，反而累积未关闭连接 - 如果非要用健康检查，可设
CONN_HEALTH_CHECKS = True（Django 4.1+），但它只在每次请求初验一次，对 WebSocket 这种长生命周期连接无意义
真正难的不是写通第一条 WebSocket 连接，而是让 group 广播不丢消息、consumer 断连时能 clean_up、反向代理（Nginx）正确透传 Upgrade 头、以及在高并发下不因 Redis 背板延迟导致消息堆积——这些都得在 Channels 的 channel layer 配置和 consumer 的异常处理里一层层抠。
