Go中无原生回调中心，但可用chan+select+goroutine实现异步非阻塞通知；关键在于订阅者自主消费，而非发布者同步调用回调函数。
go 里没有原生“回调中心”概念，但用 chan + select + goroutine 就能干净实现异步非阻塞通知——关键不是挂起调用方，而是让订阅者自己决定消费节奏。
为什么不用 sync.Map 存回调函数？
存函数本身没问题，但直接同步调用会阻塞发布者；如果回调里有 IO 或耗时操作，整个通知流就卡住。真正的非阻塞，是把“调用动作”转为“投递消息”。
- 订阅者注册时，只提供一个接收
chan interface{}（或自定义事件结构体） - 发布者往这个 chan 发送事件，不等执行结果
- 每个订阅者启动自己的 goroutine 消费该 chan，自行处理阻塞、重试、限流
- 避免用
sync.Map存函数指针 +go fn(event)：无法控制并发数，panic 会杀掉 goroutine 且无感知
如何保证订阅/退订过程线程安全且不阻塞发布？
核心是分离“管理通道”和“通知通道”：用一个带缓冲的 chan 接收订阅/退订请求，由单独 goroutine 异步更新内部映射，发布逻辑完全绕过锁。
- 定义两个命令类型：
subscribeCmd和unsubscribeCmd，含topic string和ch chan - 用
make(chan interface{}, 100)作为管理通道，缓冲足够应对突发注册/注销 - 启动一个管理 goroutine，
for range读取命令并更新map[string][]chan - 发布时只读 map（用
sync.RWMutex保护），不加写锁 —— 写操作全走管理 chan
chan 缓冲大小设多少才不丢事件又不爆内存？
没有通用值，取决于你的事件吞吐量、消费者处理速度、可接受延迟上限。硬设固定缓冲不如按 topic 分级控制。
- 高优先级通知（如告警）：用无缓冲
chan，配合select+default实现“发不出就丢”，避免阻塞发布者 - 普通业务事件：缓冲 64 或 128，够撑住短时尖峰，也防消费者卡顿导致堆积
- 绝对不能用
make(chan, 0)给多个订阅者共用 —— 一个没及时收就会让所有后续发送阻塞 - 监控
len(ch)并告警，比预设更大缓冲更有效
怎么处理订阅者 panic 或退出后 chan 泄漏？
Go 不会自动关掉无人接收的 chan，必须显式管理生命周期。最可靠方式是让订阅者自己关 channel，并在管理 goroutine 中检测关闭状态。
- 订阅者启动消费 goroutine 时，用
defer close(ch)或显式关 channel - 管理 goroutine 在每次广播前，用
select { case 检查是否已关闭 - 更稳妥的做法：订阅时返回一个
CancelFunc，调用时向管理 chan 发送退订命令并关 channel - 别依赖
recover()拦截订阅者 panic —— 它只对当前 goroutine 有效，且掩盖真实问题
真正难的不是发消息，而是让每个订阅者能独立失败、独立重启、独立背压；chan 的关闭信号、select 的超时分支、管理 goroutine 的命令队列——这些组合起来，才是可控的非阻塞。
