go语言无法用单channel实现广播因channel是点对点模型，值被一goroutine读取后即消失；安全方案是“一个入口、n个出口”，为每个订阅者分配带缓冲的独立send chan，用sync.rwmutex保护客户端map，并异步遍历分发。
Go 语言里没有内置的 Observer 接口，直接套 Java 风格写 Register()/Notify() 容易踩坑；真正的通知机制得靠 channel + sync.RWMutex + 显式分发来搭，否则不是丢消息就是死锁。
为什么不能用单个 chan interface{} 广播？
因为 Go 的 channel 是点对点模型：一个值被某个 goroutine 从 channel 中读走，就彻底消失了，其他监听者根本收不到。这不是广播，是竞态抢答。
- 常见错误现象：
for range ch启两个协程，结果只有其中一个收到每条消息 - 强行复用同一 channel，会导致部分客户端永远收不到、调试时难以定位
- 无缓冲 channel 一旦某个接收方卡住（比如网络写阻塞），整个广播协程立刻卡死
- channel 本身不携带连接生命周期信息，无法自动清理已断开的接收端
怎么安全地给所有订阅者发消息？
核心思路是“一个入口，N 个出口”——每个订阅者独占自己的 send chan []byte，服务端统一管理注册/注销，并异步遍历分发。
- 订阅时生成带缓冲的 channel：
make(chan []byte, 64)，防接收慢拖垮广播 - 用
sync.RWMutex保护map[*client]chan []byte，读多写少场景下比sync.Mutex更高效 - 广播时用
mu.RLock()遍历，对每个c.send做select { case c.send ，跳过写不进的连接 - 客户端断开后必须显式调用注销逻辑：
delete(clients, conn)+close(c.send)，否则下次广播会 panic
用 sync.Map 管理在线连接靠谱吗？
靠谱，尤其适合高频增删的 WebSocket 场景，但要注意它不解决“怎么发”问题，只管“谁在线”。
-
sync.Map免去手写锁，注册用Store(key, value)，断开用Delete(key) - 遍历时必须用
Range()，不能转成 slice 再遍历，否则可能 panic - 仍需为每个
*client配独立send chan []byte，sync.Map不替代 channel 分发逻辑 - 别在
Range回调里做耗时操作（如conn.WriteMessage()），必须中转到各自sendchannel
异步通知里最容易被忽略的点
不是并发控制，而是上下文超时和 panic 捕获——这两个漏掉，上线后第一波流量就可能把服务拖垮。
- 每个写入
c.send的操作都该包一层select { case c.send - 广播 goroutine 里别直接调
observer.Update()，要用go func() { defer func(){...}(); o.Update(...) }()拦住 panic - 如果观察者要做 HTTP 请求或 DB 写入，必须传入带 cancel 的
context.Context，否则超时请求会堆积 - 事件结构体尽量小；传大对象时用指针，但确保观察者不持久化引用，避免 GC 延迟
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
