Go中可用select配合多个专用chan实现类型安全的轻量级事件分发：为每类事件设独立chan，select各case对应一类事件，用缓冲chan控吞吐与背压，并以context控制生命周期。
用 select 配合 chan 实现事件分发
Go 中没有内置事件总线，但用 select + 多个 chan 就能模拟轻量级事件调度。关键不是“监听多个 channel”，而是让每个事件类型对应独立的 chan，再用 select 非阻塞轮询或带超时等待。
常见错误是把所有事件塞进一个 chan interface{}，然后靠类型断言分发——这会丢失类型安全，也难做优先级控制。
- 为不同事件建专用 channel：
userLoginCh chan UserEvent、paymentCh chan PaymentEvent -
select中每个case对应一个事件 channel，可加default做无事件时的保底逻辑 - 若需优先响应某类事件，把它放在
select的前面（Go 的select会随机选择就绪 case，但顺序影响可读性和调试预期） - 避免在
case分支里做耗时操作，否则会阻塞整个select轮询；应转发到 worker goroutine 或缓冲 channel 处理
用带缓冲的 chan 控制事件吞吐与背压
无缓冲 channel 是同步的，发送方必须等接收方就绪，容易导致上游 goroutine 卡死。事件高峰期若不设缓冲，要么丢事件，要么压垮生产者。
缓冲大小不是越大越好：过大会掩盖处理瓶颈，过小则频繁触发阻塞或丢弃。
- 按平均事件速率 × 可接受延迟估算缓冲长度，例如每秒 100 个事件、容忍 2 秒积压 → 缓冲设为 200
- 用
len(ch)监控当前积压量，配合日志或 metrics 告警（注意：len不是原子操作，仅作估算） - 若事件不可丢弃，缓冲满时别直接
panic或log.Fatal，而应返回错误或走降级路径（如写入本地磁盘暂存） - 慎用
cap(ch) == 0判断是否为无缓冲 channel——运行时无法可靠获取该信息，应靠设计约定
用 context.Context 协同关闭事件 channel
goroutine 泄漏常源于事件循环没收到退出信号。不能只靠 close(ch)，因为接收方可能已退出，且关闭已关闭的 channel 会 panic。
