go原生channel不支持广播，因其本质是点对点通信，单个值仅能被一个goroutine接收；需自行构建如map+mutex或sync.map等结构实现“一发全收”。
Go 语言原生 channel 不支持广播，硬塞一个 chan []byte 给多个 goroutine 读，只会让消息被随机一个协程消费掉——其他人根本收不到。真要“一发全收”，必须自己搭结构，不是加个 for range 就完事。
为什么不能直接用 channel 做广播？
因为 channel 是点对点通信原语：一个值从 ch 进去，只能被一个 for range ch，也只有一人抢到，其余阻塞或永远等不到（取决于 channel 类型）。这不是 bug，是设计使然。
- 常见错误现象：
select { case ch 突然卡住，日志里只看到部分客户端收到消息，重启后又正常——其实是某个接收方慢了，把整个广播协程拖死了 - 性能影响：用无缓冲
chan广播 N 个客户端，等于串行发 N 次，吞吐量直线下跌 - 正确思路：广播 ≠ 复用一个 channel；而是“一个入口 + N 个出口”，每个客户端独占自己的
send chan []byte
怎么安全地给所有 WebSocket 客户端发消息？
核心是分离“接收”和“发送”：所有连接共用一个 broadcast chan []byte 接收指令，但每个连接用自己的 conn.send 发出去，互不干扰。
- 每个
*websocket.Conn必须包装成结构体，内嵌send chan []byte和sync.RWMutex保护的活跃状态 - 广播协程里遍历
clients map[*connection]bool时，先mu.RLock()，再对每个c.send做select { case c.send —— 非阻塞，防卡死 - 千万别在
Subscribe的 goroutine 里直接调conn.WriteMessage()，WebSocket 连接不是线程安全的，会 panic - 示例关键片段：
for _, c := range clients { c.mu.RLock() if c.connected { select { case c.send
Redis PubSub 能替代本地连接管理吗？
不能。Redis 解决的是“消息怎么跨进程传出去”，不是“连谁、怎么发”。集群里每个服务节点仍要独立维护本机的 clients 映射。
- 每个实例启动时，用
redis.NewClient()连 Redis，并起 goroutinepubsub := client.Subscribe(ctx, "ws:global:broadcast") - 收到 PubSub 消息后，只做一件事：遍历本机
clients，往每个连接的sendchannel 里投递——这步绝不能省 - 容易踩的坑：
context没设超时，网络抖动时pubsub.ReceiveMessage(ctx)卡住整个 goroutine；或者忘记用sync.RWMutex保护clients增删，导致并发写 panic - 客户端断开时，必须显式从
clients移除、关闭sendchannel，否则广播协程往已关 channel 写会 panic
用 sync.Map 实现动态注册/注销广播通道靠谱吗？
靠谱，但要注意注销时机。用 sync.Map 存 chan 比手写 <code>map+RWMutex 更轻量，适合高频上下线场景。
- 注册函数返回只读 channel：
func (bm *Broadcaster) Register() ，内部用 <code>make(chan, 16)带缓冲 - 广播时用
Range遍历，每个ch 必须套 <code>select { case ...: default: }，避免单个慢 receiver 拖垮全局 - 注销不能只删 key，得先 close channel（如果 receiver 已退出），否则 broadcaster 持有引用导致内存泄漏
- 更稳妥的做法：receiver 启动时传入
context.Context，在done触发时自动调Unregister
真正难的不是写几行 for range clients，而是想清楚消息生命周期：谁生产、谁路由、谁消费、谁兜底丢弃、谁负责清理。漏掉任意一环，上线后就是半夜告警。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
