Django Channels 必须搭配 Redis 才能可靠推送站内消息，因其依赖 Redis 的原子性 pub/sub 和跨进程共享状态能力实现 group 广播；InMemoryChannelLayer 在多 worker 下必然丢消息，且 Channels 4.x 已彻底移除支持。
生产环境必须用 Redis，本地开发可临时用 channels_redis 连本地实例，但绝不能配 InMemoryChannelLayer —— 它在多 worker 下必然丢消息，且 Channels 4.x 已彻底移除对该类的支持。
为什么 Django Channels 必须搭配 Redis 才能可靠推送站内消息
站内消息推送本质是「一对多广播」或「定向投递」，比如用户 A 发送通知给关注者列表，或系统向某房间所有在线用户广播。Django 默认的 HTTP 请求-响应模型无法维持长连接，而 Channels 把 WebSocket 拆成两个角色：ASGI server（处理连接握手）和 worker（执行业务逻辑）。这两者之间需要共享状态——谁在哪个 group、消息发给谁、是否已送达。内存层（locmem）只在单进程内有效，一旦你启多个 daphne 或 uvicorn worker，或者用 gunicorn + gevent 部署，group 成员就不同步，消息直接消失。
Redis 提供原子性 pub/sub 和有序 list 支持，channels_redis 正是基于它实现 Group.add()、Group.send() 等语义。不连 Redis，self.channel_layer.group_add("notifications", self.channel_name) 看似成功，实际 group 是空的。
- 常见错误现象：
ChannelFull频发（缓冲区满）、消费者收不到group_send的消息、WebSocket 连接后立刻断开且日志无报错 - 验证 Redis 是否生效：启动后执行
redis-cli ping，返回PONG才算通；否则 Channels 启动不报错，但第一次group_send就卡住 - Channels 4.x 不再识别
channels.layers.InMemoryChannelLayer类名，settings 中若还写这个，项目根本起不来
settings.py 中 CHANNEL_LAYERS 配置的关键点
配置不是贴代码就能跑通，几个参数直接影响消息可达性：
立即学习“Python免费学习笔记（深入）”；
-
BACKEND必须是"channels_redis.core.RedisChannelLayer"，拼错大小写或路径（比如写成redis_core）会导致 import error -
hosts推荐用元组列表：[("127.0.0.1", 6379)]，而非字符串"redis://127.0.0.1:6379/0"—— 后者在某些版本会解析失败，且无法设置密码或 db 编号 - 如果 Redis 有密码，加
"password": "yourpass"到CONFIG字典里；若用非默认 db（如 db 1），补上"db": 1 - 别漏装依赖：
pip install channels channels-redis redis—— 注意是redis包，不是redis-py（后者已弃用）
正确示例：
CHANNEL_LAYERS = {
"default": {
"BACKEND": "channels_redis.core.RedisChannelLayer",
"CONFIG": {
"hosts": [("127.0.0.1", 6379)],
"password": "mypass123",
"db": 1,
},
},
}
routing.py 和 consumer 中如何组织站内消息逻辑
站内消息不是简单 echo，要区分「用户专属频道」和「全局通知组」。比如用户 ID 为 u123，可让前端连 ws://host/ws/notify/u123/，consumer 在 connect 时将其加入 group_notify_u123；系统发消息时调用 self.channel_layer.group_send("notify_u123", {...})。
- 路由必须独立于 Django
urls.py，新建routing.py（通常放在项目根目录），并在asgi.py中指向它，否则 WebSocket 请求会被 HTTP router 拦截 -
ProtocolTypeRouter里"http"和"websocket"顺序不能反，否则所有请求都走 URLRouter，WebSocket 握手失败 - consumer 中避免在
connect里做耗时操作（如查数据库），否则连接延迟；用户身份建议从 ASGI scope 中提取scope["user"]（需配合AuthMiddlewareStack） - 发送消息时，
type字段必须对应 consumer 中定义的异步方法名，比如type: "notify_message"就要实现async def notify_message(self, event):
consumer 片段示意：
class NotifyConsumer(AsyncWebsocketConsumer):
async def connect(self):
self.user_id = self.scope["url_route"]["kwargs"]["user_id"]
self.group_name = f"notify_{self.user_id}"
await self.channel_layer.group_add(self.group_name, self.channel_name)
await self.accept()
async def notify_message(self, event):
await self.send(text_data=json.dumps({
"type": "notification",
"content": event["content"],
"timestamp": event["timestamp"],
}))
前端连接与消息接收的硬性要求
浏览器 WebSocket 地址必须以 ws:// 或 wss:// 开头，绝对不能用 http://。开发时若用 runserver，Django 默认不支持 WebSocket，必须用 daphne 或 uvicorn --lifespan off 启动 ASGI server。
- Chrome 控制台报
Error during WebSocket handshake: net::ERR_CONNECTION_REFUSED，第一反应不是代码问题，而是 server 没起来或端口不对（daphne默认 8000，但需确认是否被占用） - 连接后没收到消息？先检查 consumer 的
group_send调用是否真的执行了（加print或日志），再确认 group 名是否完全一致（大小写、下划线、前缀都不能差） - 消息内容必须是字符串，
send(text_data=...)传 dict 会直接报错；务必用json.dumps序列化 - 别在 consumer 里直接操作数据库写入记录——那属于业务逻辑，应放在视图或 task 中触发
group_send，consumer 只负责转发
真正容易被忽略的，是 group 名的生命周期管理。用户断开连接时，disconnect 方法里必须调用 group_discard，否则 group 里残留无效 channel，下次发消息仍会尝试投递到已关闭的连接，造成资源泄漏。这个步骤没有自动机制，全靠手动补全。
