不能直接用 map[string][]func(interface{}) 存订阅者，因为 Go 原生 map 不支持并发读写，多 goroutine 调用 Subscribe 和 Publish 会触发确定性 panic；需用带锁的 subList 封装切片或 sync.Map 配合额外同步机制。
为什么不能直接用 map[string][]func(interface{}) 存订阅者
因为 Go 的原生 map 不支持并发读写，一旦多个 goroutine 同时调用 Subscribe 和 Publish，就会触发 fatal error: concurrent map writes。这不是偶发 bug，而是确定性 panic。
常见错误写法是：启动一个全局 map[string][]func(interface{})，然后在 Subscribe 里直接 subs[topic] = append(subs[topic], fn) —— 这在压测或真实流量下必崩。
- 别指望靠文档说“只在初始化时注册”来规避：微服务里配置热更新、插件动态加载、HTTP handler 内注册都意味着运行时写入
-
sync.RWMutex能解决，但遍历 + 删除时容易漏锁或死锁（比如遍历中删 slice 元素） -
sync.Map是更轻量的选择，但它只保证外层 key-value 并发安全；value 是[]func(interface{})时，仍需额外锁保护切片操作 - 真正推荐的做法是把 value 封装成带锁的结构体，例如
type subList struct { mu sync.RWMutex; fns []func(interface{}) }
如何让每个订阅回调不互相拖垮
发布时若同步逐个调用回调函数，某个回调卡住（比如 HTTP 请求没设 timeout、DB 查询慢），整个 Publish 就会阻塞，上游业务（如 API 响应）直接超时。
正确做法不是“加个 goroutine 包一层”就完事，而是必须控制 panic 传播和资源泄漏：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 每个回调必须包裹
defer func() { recover() }()，否则一个 panic 会让后续所有订阅者收不到消息 - 耗时操作（如网络请求、DB 写入）不能放在回调主线程里，要显式启新 goroutine，但得绑定
context.Context控制生命周期 - 别在
Publish中统一加timeout—— 这会中断已开始执行的回调，且无法判断哪些成功、哪些被丢弃 - 如果回调本身不可控（比如第三方 SDK），建议改用 channel 模型，把消息投递和消费解耦
取消订阅为什么经常失效
调了 Unsubscribe("user.created", handler)，但之后发事件，handler 还是被执行了。这不是逻辑写错，而是 Go 函数比较的底层限制：
- 闭包、方法值、匿名函数即使内容完全一样，
==也返回false；无法靠地址比较精准移除 - 常见错误是遍历切片做
if f == targetFn，永远匹配不上 - 可行方案只有两个：一是给每个订阅者分配唯一
id（如uuid.NewString()），存进结构体再注册；二是改用chan interface{}模型，用通道本身作标识（Unsubscribe(topic, ch)） - 用通道模型时，
Unsubscribe必须同时close(ch)并从sync.Map中移除，否则 goroutine 会一直阻塞在for range ch上
主题命名和消息结构怎么避坑
看似只是字符串和类型定义，实际影响日志追踪、监控切片、灰度发布和未来对接 Kafka/NATS。
- 主题名必须带业务域前缀，
"user.created"可行，"created"不行 —— 后者会导致风控、积分、通知模块全挤在一个 topic 下，后期无法单独限流或屏蔽 - 消息别用裸
interface{}，容易在消费端msg.(string)失败 panic；统一定义type Event struct { Topic string; Payload interface{} }，发布方只传这个结构体 - 如果 Payload 是结构体指针（如
*Order），多个订阅者并发修改会引发数据竞争；传值更安全，小对象 GC 压力可控 - 测试时最容易漏掉“订阅后才发事件”的时序问题：务必用
sync.WaitGroup或time.After(10ms)确保订阅完成再发，否则可能收不到第一条消息
