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 卡死。事件高峰期若不设缓冲，要么丢事件，要么压垮生产者。
缓冲大小不是越大越好：过大会掩盖处理瓶颈，过小则频繁触发阻塞或丢弃。
立即学习“go语言免费学习笔记（深入）”；
- 按平均事件速率 × 可接受延迟估算缓冲长度，例如每秒 100 个事件、容忍 2 秒积压 → 缓冲设为 200
- 用
len(ch)监控当前积压量，配合日志或 metrics 告警（注意：len不是原子操作，仅作估算） - 若事件不可丢弃，缓冲满时别直接
panic或log.Fatal，而应返回错误或走降级路径（如写入本地磁盘暂存） - 慎用
cap(ch) == 0判断是否为无缓冲 channel——运行时无法可靠获取该信息，应靠设计约定
用 context.Context 协同关闭事件 channel
goroutine 泄漏常源于事件循环没收到退出信号。不能只靠 close(ch)，因为接收方可能已退出，且关闭已关闭的 channel 会 panic。
正确做法是用 context.Context 控制生命周期，channel 仅负责数据传递。
- 启动事件循环时传入
ctx，在select中加入case - 不要在循环内反复调用
ctx.Err()判断，而是依赖通道通知 - 关闭 channel 应由唯一 owner 执行（通常是启动 goroutine 的函数），且只 close 一次；可用
sync.Once包裹 - 若需向多个 consumer 广播事件，用
sync.Map存 channel 列表，逐个 close —— 但更推荐用 fan-out 模式：一个 source channel + 多个独立 receiver goroutine
避免在 channel 上传递大对象或未导出字段
Go 的 channel 传递的是值拷贝。若结构体含大量字段或指针指向大内存块（如 []byte、map），拷贝开销显著，还可能引发意外共享。
典型误用：把 HTTP 请求体 *http.Request 直接 send 进 channel，结果下游修改了 req.Body，上游复用时出错。
- 只传轻量标识符（ID、时间戳、枚举）或只读视图（如
struct{ ID int; Status string }） - 需传递大对象时，改用指针 + 明确所有权约定，或用
sync.Pool复用临时结构体 - 跨 goroutine 共享状态优先考虑
sync.Mutex或atomic，而非靠 channel 同步 - 注意：
interface{}类型的 channel 会隐式装箱，增加 GC 压力；尽量用具体类型声明 channel
真正难的不是写对 channel 语法，而是判断哪个环节该用 channel、哪个该用 mutex、哪个该用 context cancel——边界模糊时，先画出数据流向图，再决定通信还是共享。
