gorilla/websocket本地广播在集群中必然失效，因各实例内存隔离，A节点无法访问B节点的hub.clients映射，导致仅本机连接能收到消息；须用Redis Pub/Sub跨实例中继，各节点订阅同一频道后向本地连接投递。
单机 gorilla/websocket 的 broadcast 机制天生无法跨实例，强行用本地 map[*Client]bool 群发，80% 的在线用户收不到消息——这不是 bug，是架构局限。
为什么 gorilla/websocket 本地广播在集群里必然失效
每个 Go 实例进程内存完全隔离：hub.clients 只存本机连接，A 实例里 user_id=u123 的 client，B 实例根本看不到。调用 hub.broadcast([]byte{...}) 后，只有当前实例的 goroutine 能遍历到自己的 map，其他机器静默丢弃。
常见错误现象包括：
- 前端无报错、无重连，但消息“发出去了却没人收到”
- 用
redis-cli pubsub channels查不到订阅，或PUBSUB NUMSUB ws:global:broadcast返回 0 - 日志里反复出现
websocket: close sent却没触发onclose，说明连接早被另一实例接管或已断开
Redis Pub/Sub 是最轻量可行的跨实例中继方案
不用 Kafka、RabbitMQ，github.com/go-redis/redis/v8 + 原生 PUBLISH/SUBSCRIBE 就够用。延迟低（通常 PUBLISH 和 PSUBSCRIBE）、Go 客户端成熟。
关键设计点：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 所有实例都
PSUBSCRIBE ws:global:broadcast和PSUBSCRIBE ws:user:*（用通配符支持单发） - 消息体只传必要字段，例如：
{"user_id":"u123","msg":"hi","type":"text"}，绝不要序列化*Client或http.ResponseWriter - 单发必须带
target_user_id，各实例收到后比对本地client.UserID，命中才写入client.Sendchannel - 广播用固定 channel 名如
ws:global:broadcast，避免按房间或业务分 channel 导致订阅爆炸
单发必须解决“用户落在哪台实例”这个前提问题
没有这个信息，user_id 就只是个字符串，没法路由。常见做法有三种：
- 登录/握手阶段，由网关或服务发现组件把
user_id → pod_ip:port映射写入 Redis，TTL 设为略长于心跳周期（比如 65s） - 客户端首次连接时，服务端生成并返回一个
instance_id（如svc-ws-01），前端存 localStorage，后续单发请求带上该 ID - 用一致性哈希：对
user_id做sha256取模，映射到预设的实例列表索引，要求实例数稳定、扩缩容需迁移部分 key
注意：如果用第一种方式，务必在 client.Close() 时主动 DEL 对应 key，否则会残留大量过期绑定。
本地 clients map 仍要保留，但职责已变
它不再承担“状态中心”角色，而是退化为纯本地缓存：只管本机连接的读写、心跳、异常关闭清理。所有跨实例逻辑必须绕过它，走 Redis 中继。
容易踩的坑：
- 在
Write方法里直接调c.Socket.WriteMessage，没做select { case 判断，导致 panic 后 goroutine 泄漏 - Redis 订阅 goroutine 没加
defer cancel()，实例重启时残留连接堆积 - 用
json.RawMessage解包消息体却忘了检查len(data) == 0，空 payload 触发invalid character '}'错误 - 没对
user_id做白名单校验，恶意构造target_user_id可能打爆某实例内存
真正难的不是代码怎么写，而是想清楚哪些状态必须外置、哪些逻辑必须收敛、以及每次连接建立/断开时，Redis 里那几条 key-value 是否严格同步。漏掉任意一环，群发就成盲发，单发就成乱发。
