go中真正解耦的发布订阅要求发布方仅依赖topic字符串和事件结构体，不导入subscribe函数或订阅者类型；使用sync.map存储channel切片，避免并发panic；发送必须非阻塞，遍历channel时用select{case ch: default:}防止阻塞。
Go 里实现真正解耦的发布订阅，核心不是“能发能收”，而是发布方连 Subscribe 函数都不需要 import，也不依赖任何订阅者类型或生命周期——只认 topic 字符串和事件结构体。
用 sync.Map 存 channel 切片，别自己锁 map
高频并发注册/退订 + 遍历通知时，sync.Map 比 map + sync.RWMutex 更稳。自己加锁容易在 range 过程中删 key 导致 panic，而 sync.Map.Range 是快照语义，发布时只通知“当时已注册”的 subscriber，符合预期。
-
sync.Map的 value 类型建议是[]chan Event（不是[]func(Event)），每个 subscriber 独占 channel，天然隔离 - 别用
map[string]chan Event：一个 topic 只能有一个接收者，违背 pub/sub 多对多本质 - 注册时用
LoadOrStore获取切片，再append新 channel；退订时需遍历并重建切片（注意 copy-on-write）
发送必须非阻塞：select { case ch 是底线
一旦某个 subscriber 的 channel 满了或消费者卡住，ch 就会阻塞整个 Publish 流程——尤其在 HTTP handler 里发事件时，直接拖垮接口响应。
- 每个 topic 下遍历所有 channel 时，必须用
select { case ch，default 分支可记录丢弃数或打日志 - 不要在发送路径上做
select { case ：开销大，且掩盖了 channel 是否 ready 的事实 - channel 缓冲大小建议设为 16 或 32，太小易丢，太大占内存且延迟不可控
退订必须关 channel，否则 goroutine 泄漏
只从 sync.Map 里删掉 channel 引用，却不 close(ch)，会导致消费 goroutine 一直阻塞在 for range ch 上，反复调用 Subscribe/Unsubscribe 后 runtime.NumGoroutine() 会持续上涨。
-
Unsubscribe返回的取消函数，内部必须先close(ch)，再从sync.Map中删除 - 消费者应写成
for msg := range ch形式，这样close(ch)后循环自动退出 - 别在
Subscribe里直接启动 goroutine 处理消息：生命周期难管理，容易漏 cancel
事件类型必须带泛型或统一接口，拒绝裸 interface{}
用 interface{} 当事件参数，等于把类型检查全推到运行时——event.(*UserCreated) 一错就 panic，而且 IDE 和 go vet 都没法帮你看出来。
- 推荐定义
type Event[T any] interface { Type() string; Timestamp() int64; Payload() T }，编译期约束 payload 类型 - 或者轻量方案：
type Event struct { Type string; Data []byte }，用 JSON 序列化，消费端json.Unmarshal(e.Data, &user) - 绝对避免
map[string]interface{}嵌套结构：字段名拼错、类型不一致、嵌套深了反序列化易失败
最难被注意到的点是：真正的解耦不在内存内 channel 怎么转，而在 topic 命名是否带业务域、事件是否可重放、以及失败后要不要进死信队列——这些决定了你的系统是玩具还是能上生产。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
