Go 中实现单通道多监听器的广播模式（Fan-Out）

在 go 中，一个 channel 无法被多个 goroutine 同时“接收”同一份数据——默认行为是竞争式消费，仅有一个接收方能拿到消息。要实现“一个事件通知多个处理者”，需借助 fan-out 模式，通过 goroutine 复制消息并分发到多个独立 channel。

Go 的 channel 是点对点通信原语，不具备内置广播能力。当你将同一个 incoming chan Event 同时用于 processEmail 和 processPagerDuty 的 随机选择一个就绪的接收方完成接收（基于调度公平性），因此你观察到“只有第一个启动的 goroutine 收到事件”——这并非 bug，而是 channel 的设计本质。

✅ 正确解法：使用 Fan-Out（扇出）模式 —— 由一个中央分发 goroutine 从源 channel 读取事件，并主动复制、并发发送给多个专用 listener channel：

type Event struct { Host, Command, Output string } // 定义多个独立的 listener channel（每个处理逻辑独占） var ( emailCh = make(chan Event, 10) // 缓冲避免阻塞分发者 pagerDutyCh = make(chan Event, 10) incoming = make(chan Event, 10) // 原始输入通道（如 HTTP API 写入） ) // 中央分发器：读取 incoming，广播到所有 listener channel func broadcast() { for e := range incoming { // 并发发送（非阻塞关键！需配合缓冲或 select 超时） go func(event Event) { select { case emailCh <- event: default:>
⚠️ 关键注意事项：
 缓冲至关重要：所有 listener channel（emailCh, pagerDutyCh）必须设置合理缓冲容量（如示例中的 10），否则当某个处理器卡住（如网络延迟、panic 未恢复），广播 goroutine 会在 select 的 case 中永久阻塞，导致整个事件流中断。
 避免 goroutine 泄漏：示例中使用 select { case ch 
 不要直接关闭 incoming 后再 range：broadcast() 中的 for e := range incoming 依赖 channel 关闭，但生产环境通常长期运行，应通过 context 控制生命周期。
 扩展性提示：若 listener 数量动态变化，可将 emailCh/pagerDutyCh 抽象为 []chan Event 切片，用 for _, ch := range listeners 循环分发。
总结：Go channel 本身不支持广播，但通过「一个读 + 多个写」的 fan-out 架构，配合缓冲 channel 和非阻塞发送，即可安全、高效地实现“一事件、多消费者”的经典发布-订阅语义。