纯 Redis Pub/Sub 无法直接支撑多实例数据同步，因其不存消息、不记订阅者、不保证送达，仅作“发即忘”管道；必须补足位点管理、重试机制和客户端生命周期感知，否则必然丢消息。
纯 Redis Pub/Sub 无法直接支撑多实例数据同步——它不存消息、不记订阅者、不保证送达，只做“发即忘”管道。真要跨节点同步状态或事件，必须补足位点管理、重试机制和客户端生命周期感知，否则上线后丢消息是常态。
go-redis/v9 的 Subscribe 为什么收不到消息
常见错误现象：Subscribe(ctx, "topic") 成功返回，但 ReceiveMessage() 一直阻塞、无报错、也无消息；或者只在发布端重启后才突然收到几条积压消息。
- 频道名拼写不一致：大小写、空格、冒号位置（如
"user:update"vs"user:update "）都会导致静默失败，Redis 不校验频道合法性 - 订阅启动晚于发布：Pub/Sub 无历史回放，
Subscribe前发布的消息全部丢失 - ctx 被提前 cancel：比如用
context.Background()启动，但父 goroutine 已退出，导致底层连接被关，ReceiveMessage()返回context.Canceled却没被检查 - 没调
defer pubsub.Close()：连接泄漏，Redisclient list中 idle 连接堆积，后续新订阅可能被限流或拒绝
用 XREADGROUP 替代 SUBSCRIBE 实现可靠同步
当同步涉及用户状态、订单变更、配置推送等不能丢的场景，必须放弃原生 Pub/Sub，改用 Redis Stream + 消费组。这是目前 Go 生态最落地的方案。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 发送端统一走
XADD sync:events * data "{\"key\":\"order:789\",\"op\":\"paid\"}"，消息自动持久化 - 每个服务实例创建独立消费组：
XGROUP CREATE sync:events group-node-a $ MKSTREAM，$表示从最新开始消费 - 拉取时用
XREADGROUP GROUP group-node-a consumer-1 COUNT 10 STREAMS sync:events >，>表示只读未分配消息 - 处理成功后必须显式
XACK sync:events group-node-a <id>，否则消息会重复投递 - 别复用同一个
consumer-1名：多 goroutine 并发读同一消费组时，应为每个 worker 分配唯一 consumer 名，避免争抢位点
广播消息到本机所有 WebSocket 连接的正确姿势
Redis Pub/Sub 在这里只负责「通知本机该广播了」，不是把消息直接推给所有客户端——连接管理永远是单机职责。
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Map存在线连接：clients.Store(conn, &client{send: make(chan []byte, 32)})，避免 map 并发写 panic - 收到 Redis 消息后，**不要**在
pubsub.Channel()的 goroutine 里直接调conn.WriteMessage()，必须中转进每个连接自己的sendchannel -
sendchannel 必须带缓冲（如32），否则某个卡住的客户端会让整个广播协程阻塞在c.send <- msg - 广播循环中用
clients.Range()遍历，内部自动加锁，无需额外RLock；遍历时若某连接已断开，其sendchannel 可能已关闭，写入会 panic，需用select { case c.send <- msg: ... default: }非阻塞发送 + 日志告警 - 每个连接的
sendgoroutine 要监听conn.SetReadDeadline()或心跳超时，及时关闭 channel 并从clients中清理
多节点间状态同步的边界在哪
Redis Pub/Sub 解决的是「哪个节点需要触发本地广播」，不是「哪些客户端在线」。后者永远得靠各节点自己维护连接映射，跨节点查在线列表是反模式。
- 别在收到 Redis 消息后，再去 Redis 里查
KEYS ws:*或SMEMBERS online-users—— 这既慢又不准，且破坏单机自治原则 - 如果业务要求「全网精准在线数」，必须引入额外协调层（如 etcd 注册+租约心跳），Pub/Sub 只做低延迟事件分发
- 集群扩容时，新节点启动后需自行完成 Stream 位点初始化（
XGROUP CREATE ... $或指定 ID），不能依赖旧节点同步位点 - Stream 消息体别过大：超过 1MB 容易触发 Redis OOM 或网络分片失败，大 payload 应存对象存储，Redis 只传 ID
