Go channel不支持广播，扇出需显式复制消息到多个独立channel；直接多goroutine读同一channel会导致竞态、丢数据或deadlock；正确做法是用分发goroutine从源channel读一次并复制发送至多个目标channel。
Go 的 channel 本身不支持广播，多个 goroutine 直接从同一个 chan T 读，是竞争式消费——每次只有一人能拿到数据。所谓“扇出（fan-out）”，本质是**显式复制消息并分发到多个独立 channel**，不是让多个 goroutine 共享读一个 channel。
为什么直接 go f(ch) 多次会丢数据或死锁
常见错误写法：go worker(ch) 调用三次，所有 worker 都从同一个 ch 读。问题在于：
- 数据被随机一个 goroutine 消费，其余两个永远等不到——这不是扇出，是竞态
- 如果上游没关
ch，所有worker会在for range ch卡住，导致fatal error: all goroutines are asleep - deadlock - 无法保证每个消费者都收到同一份事件（比如日志通知邮件和告警）
正确扇出：必须用分发 goroutine 做消息复制
核心逻辑只有一个：起一个 goroutine 从源 channel 读一次，再把值分别发给多个目标 channel。示例：
func fanOut(in <-chan Event, emailCh, pagerDutyCh chan<- Event) {
for e := range in {
// 必须并发发送，避免一个阻塞拖垮全部
go func(event Event) {
select {
case emailCh <- event:
default:
// 缓冲满时丢弃或记录，防止分发器卡死
}
}(e)
go func(event Event) {
select {
case pagerDutyCh <- event:
default:
// 同上
}
}(e)
}
}关键点：
立即学习“go语言免费学习笔记（深入）”；
- 每个
select发送都用独立 goroutine +select+default，防止单个 consumer channel 满导致整个分发阻塞 - 闭包参数
event Event必须显式传入，否则循环变量复用会导致所有 goroutine 发送最后一条数据 - 源 channel
in关闭后，这个分发 goroutine 自动退出，无需手动 close 目标 channel（由各 consumer 自行决定何时关）
扇出时缓冲大小（lag）怎么设才不拖慢也不爆内存
目标 channel 是否带缓冲、缓冲多大，直接影响扇出行为：
- 无缓冲 channel：
make(chan Event)—— 分发器会卡在emailCh 直到有 goroutine 准备好接收，适合低频、强实时场景，但极易因 consumer 慢而阻塞整个扇出流 - 带缓冲 channel：
make(chan Event, 10)—— 推荐做法。缓冲区大小 ≈ consumer 平均处理耗时 × 预估峰值吞吐。设太小（如 1）等于没缓；设太大（如 10000）可能积压旧数据、OOM - 不要依赖缓冲掩盖 consumer 性能问题：如果
processEmail常超时，应优化它本身，而不是把emailCh缓冲调到 1000
扇出后 consumer 怎么安全退出不漏收
consumer 不能假设“只要读不到就说明结束了”。正确方式是监听源 channel 关闭信号，或配合 done channel：
- 若分发器明确会关目标 channel（如任务固定），consumer 可用
for e := range emailCh—— 它会在 channel 关闭后自动退出 - 若目标 channel 不会关闭（如长连接心跳事件），consumer 必须自己管理生命周期，例如：
select { case e := - 切勿在 consumer 里主动
close(emailCh)—— 这会破坏扇出结构，其他 goroutine 再写就 panic
最易被忽略的点：扇出不是语法糖，是显式复制 + 并发投递；没做复制，就不是扇出，只是多个 goroutine 在抢同一份数据。
