Go语言可通过goroutine+channel+接口自建轻量事件系统，核心是解耦通知与执行、避免goroutine泄漏、控制并发与生命周期；需用带缓冲channel、显式管理监听器启停及资源回收。
Go 语言本身不提供内置的“事件驱动框架”，但用 goroutine + channel + 接口组合，就能写出轻量、可控、高性能的事件系统。关键不是套框架，而是理解怎么避免 goroutine 泄漏、怎么控制并发规模、怎么让监听器不阻塞分发器。
为什么不用第三方事件库？
多数 Go 事件库（如 github.com/asaskevich/EventBus）默认用无缓冲 channel 或同步调用，一监听器卡住，整个 dispatch 就挂住；有的还带反射、泛型抽象，增加 GC 压力和调用开销。实际业务中，你更需要的是：明确的生命周期控制、可取消的监听、带超时的触发、按需并发 —— 这些都得自己搭。
- 同步分发（直接函数调用）适合简单场景，但监听器出错或阻塞会拖垮主流程
- 用无缓冲
channel转发事件，容易因监听器未及时收导致发送方 goroutine 永久阻塞 - 泛型事件结构（如
type Event[T any]）在高频事件下会增加接口转换开销，不如按业务定义具体事件类型
用 channel + goroutine 实现非阻塞分发
核心是把“通知”和“执行”解耦：分发器只负责把事件推到每个监听器专属的 chan，监听器自己启 goroutine 消费。这样即使某个监听器慢，也不影响其他监听器或新事件入队。
type Dispatcher struct {
listeners map[string][]chan Event
mu sync.RWMutex
}
<p>func (d *Dispatcher) Dispatch(e Event) {
d.mu.RLock()
defer d.mu.RUnlock()
for _, ch := range d.listeners[e.Name] {
select {
case ch <- e:
default:
// 队列满时丢弃或打日志，不阻塞
}
}
}</p><p>func (d *Dispatcher) Register(name string, ch chan Event) {
d.mu.Lock()
defer d.mu.Unlock()
d.listeners[name] = append(d.listeners[name], ch)
}
-
ch必须是带缓冲的（例如make(chan Event, 10)），否则select的default分支永远不触发 - 监听器启动逻辑要自己写，且必须用
for range持续消费，不能只收一次就退出 - 注册时没做去重，重复注册同一
chan会导致事件被多次投递
如何安全关闭监听器并回收资源
监听器 goroutine 不能靠 close(ch) 来退出 —— for range 收完缓存后会直接退出，但你无法知道它是否已处理完所有积压事件。正确做法是加一个 done 通道配合 select。
立即学习“go语言免费学习笔记（深入）”；
func startListener(ch chan Event, done <-chan struct{}) {
for {
select {
case e := <-ch:
handleEvent(e)
case <-done:
return // 主动退出
}
}
}
- 不要在监听器里直接
close(ch)，这会让其他还在注册的监听器 panic -
done应该是context.Context.Done()，方便统一 cancel - 如果监听器内部有网络调用或 DB 查询，记得给它们也传入 context 并设 timeout
性能敏感点：避免频繁分配和锁争用
高频事件下，Dispatcher.Dispatch 是热点路径。每次都要 RWLock + 遍历 slice + 发送到多个 chan，容易成为瓶颈。
- 把
listeners拆成 per-event-name 的sync.Map，避免全局读写锁 - 监听器
chan缓冲区大小要根据平均事件间隔和处理耗时预估，太小丢事件，太大吃内存 - 事件结构体尽量用值传递，避免指针逃逸；如果字段多，考虑用
unsafe.Pointer+ 对象池复用，但需确保线程安全 - 不要在事件分发路径上做 JSON marshal/unmarshal，提前序列化好或用二进制协议
真正难的不是写出来，是让监听器既能并发跑又不互相干扰，还能随时停、不漏事件、不出 panic —— 这些细节都在 select 分支、chan 容量、context 传递和锁粒度里藏着。
