gorilla/websocket默认模式不支持百万连接，因其内存驻留状态、无生命周期钩子、需手动实现心跳/广播/重连；redis应存user_id、node_id、room_ids、last_heartbeat、conn_created_at等可序列化元数据；广播需结合redis pub/sub与本地内存过滤，并用lpush缓冲兜底；注册注销用channel串行化避免竞态。
gorilla/websocket 会话管理为什么撑不住百万连接
直接用 gorilla/websocket 的默认模式（每个连接起一个 goroutine + 阻塞读写）在连接数超过 5k 后就会明显抖动，不是代码写错了，而是设计上就不是为海量长连接准备的。它把连接状态全压在内存里，没有外部存储兜底；心跳、断线重连、广播路由都得自己补；更关键的是——它不提供会话生命周期钩子，你根本没法在连接关闭时可靠地清理关联资源（比如 Redis 中的用户状态、房间成员列表）。
Redis 作为会话中心必须存哪些字段
光把 *websocket.Conn 对象塞进 Redis 是没用的，它不能序列化，也不跨进程。真正要存的是能重建上下文的元数据：
-
user_id：字符串，用于关联业务用户（不是连接 ID） -
node_id：当前处理该连接的服务器节点名（如"ws-node-01"），用于故障转移时定向拉取 -
room_ids：字符串数组，记录该用户当前加入的所有房间（避免广播时遍历全量连接） -
last_heartbeat：时间戳，服务端主动检测失联的依据（比依赖 TCP keepalive 更准） -
conn_created_at：毫秒级时间戳，辅助做连接老化淘汰（比如 >24h 无活动自动踢出）
这些字段统一存成 JSON，用 SET key value EX 3600 带过期，别用哈希结构——单 key 操作原子性更强，也方便用 SCAN 批量捞离线用户。
分布式环境下广播消息怎么避免重复投递
多个 ws 节点同时收到同一条业务消息（比如“用户 A 发送了聊天消息”），如果各自遍历本地连接发一遍，订阅者就会收两次。正确做法是借 Redis 的 PUB/SUB 做消息中转：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 业务逻辑层不直连 WebSocket 连接，而是
PUBLISH chat:room:123 "{...}" - 每个 ws 节点都
SUBSCRIBE自己负责的房间前缀（如chat:room:*） - 收到消息后，只向本节点内存中匹配
room_ids的连接投递 - 关键点：
PUB/SUB消息不落地，节点重启就丢——所以必须搭配上面说的 Redis 元数据做兜底重放（比如用LPUSH chat:room:123:buffer缓存最近 10 条）
连接注册/注销的竞态问题怎么破
用户快速刷新页面时，旧连接还没来得及 unregister，新连接又来了，register 和 unregister 两个 goroutine 可能同时改 map，导致 panic 或状态错乱。别用 sync.RWMutex 锁整个 map——锁粒度太粗，高并发下成瓶颈。
推荐方案是用 channel 做串行化入口：
- 定义
type registerOp struct{ userID string; conn *websocket.Conn; op string } - 所有注册/注销操作都走同一个
chan registerOp - 后台起唯一 goroutine 消费这个 channel，按顺序执行
SET user:xxx node_id和DEL conn:xxx - 这样既保证原子性，又不阻塞主请求流——HTTP handler 只管发消息进 channel 就返回
真正的难点不在代码怎么写，而在于：你得想清楚哪些状态变更必须强一致（比如用户退出房间），哪些可以最终一致（比如在线时长统计）。混在一起处理，再好的架构也会被拖垮。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
