Django传统视图基于HTTP请求-响应模型，无法维持长连接，高频消息需反复建连，导致延迟高、服务器压力大；万人聊天必须用WebSocket+Channels，其ASGI架构配合Redis Channel Layer实现跨进程广播与稳定低延迟通信。
为什么直接用 Django Views 做不了万人聊天室
Django 的传统视图基于 HTTP 请求-响应模型，每次消息发送都要建立新连接、走完整生命周期，根本扛不住高频短连接。WebSocket 才是实时通信的基础设施，而 Channels 就是让 Django 支持 WebSocket 的扩展层——它把请求从 WSGI 切到 ASGI，并引入 channel layer 作为进程间消息总线。
- HTTP 视图无法维持长连接，用户发一条消息就要 reload 页面或轮询，延迟高、服务器压力爆炸
-
Channels启动ASGI服务（如daphne或uvicorn），允许单连接持续收发消息 - 真正支撑“万人在线”的不是 WebSocket 连接本身，而是背后的
channel_layer：它必须脱离内存（不能用channels.layers.InMemoryChannelLayer），否则多 worker 之间消息不通，横向扩展失效
必须替换默认的 InMemoryChannelLayer
本地开发时 channels 默认用内存层，一跑 runserver 看似能聊，但只要启两个 worker、或换台机器连进来，消息就彻底丢失——这是上线前最常踩的坑。
- 生产必须用支持广播和持久化的后端：
Redis是唯一被官方文档明确推荐且稳定验证过的选项 - 配置示例（
settings.py）：CHANNEL_LAYERS = { "default": { "BACKEND": "channels_redis.core.RedisChannelLayer", "CONFIG": { "hosts": [("127.0.0.1", 6379)], }, }, } - 别碰
database或自研层：Redis 的 pub/sub + list 结构天然适配 group broadcast 场景，延迟稳定在毫秒级；数据库层在高并发下会成瓶颈，且不保证消息顺序
Consumer 中 group_add / group_discard 必须配对使用
聊天室靠 group 实现广播，但很多人只记得进群加 group，忘了退出时清理——导致 Redis 中 group 成员列表不断膨胀，最终内存溢出或消息发给已断连的 socket。
- 每个 WebSocket 连接在
connect里调用self.channel_layer.group_add("chat_room", self.channel_name) -
必须 在
disconnect里显式调用self.channel_layer.group_discard("chat_room", self.channel_name) - 不要依赖浏览器自动断开触发 cleanup：网络抖动、手机切后台、强制 kill app 都可能让 disconnect 不被调用，得靠 Redis 的 channel TTL 或外部心跳机制兜底（比如用
redis-cli --scan --pattern "asgi:*" | xargs redis-cli del定期清理）
前端 WebSocket 连接 URL 要带正确协议和路径
Django Channels 对 WebSocket 路由的处理和 HTTP 完全不同，前端连错地址会导致 403、404 或静默失败，且错误信息极其模糊。
立即学习“Python免费学习笔记（深入）”；
- 后端路由（
routing.py）定义的是 ASGI 路径，比如path("ws/chat/", ChatConsumer.as_asgi()) - 前端 JS 必须用
wss://（HTTPS 站点）或ws://（HTTP 开发环境），且路径严格匹配：new WebSocket("wss://yourdomain.com/ws/chat/") - 错误写法：
"wss://yourdomain.com/chat/"（少/ws/）、"wss://yourdomain.com/ws/chat"（结尾缺斜杠，部分版本会 404） - 如果用 Nginx 反代，必须透传 Upgrade 头，否则连接降级为 HTTP：
location /ws/ { proxy_pass http://localhost:8000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; }
真实压测到万人时，Redis 内存占用、consumer 异步阻塞、Nginx 连接数限制、SSL 握手耗时这些点才会暴露出来——但所有问题都始于最初没把 channel_layer 换掉，或者 group 没 clean 干净。
