chan struct{} 是广播信号的唯一合理选择，因其语义不可篡改：发送端只能发 struct{}{}，接收端只关心“有没有”；chan bool 易混淆 false 含义，chan int 语义不清且浪费内存；struct{}{} 占 0 字节、行为确定、编译器优化充分，close(done) 才是真正广播。
为什么 chan struct{} 是广播信号的唯一合理选择
不是因为它“轻”，而是因为它的语义不可篡改：发送端只能发 struct{}{}，接收端只关心“有没有”，不关心“是什么”。chan bool 会混淆 false 是信号还是零值；chan int 要纠结发 0 还是 1，还浪费 7 字节内存；而 struct{}{} 占 0 字节，len(ch) 和 cap(ch) 行为一致，且编译器能做更多优化。
实际编码中，只要看到信号用途的 channel，就该直接写成：
done := make(chan struct{})别用别名、别封装、别加注释解释“这是信号”，它本身就是信号。
close(done) 才是真正的广播，不是 done
往 chan struct{} 发一次值，只能唤醒一个阻塞的接收者；哪怕带缓冲（如 make(chan struct{}, 10)），也最多唤醒 10 个。但 close(done) 会让所有当前及后续的 立即返回 <code>struct{}{} 且 ok == false —— 这才是广播的本质。
- 单次通知（如服务启动完成）：用无缓冲
chan struct{}+close() - 多次通知（如心跳）：才考虑带缓冲，但必须配
select { case done 防卡死 - 绝不在循环里反复
done 去模拟广播——channel 关闭后再次 send 会 panic：<code>send to closed channel
如何避免广播协程被某个 receiver 拖垮
Go 原生 channel 是点对点的，要实现一对多，必须靠分发协程中转。但中转逻辑极易因某个慢 receiver 导致整个广播流阻塞。
关键防护措施：
- 所有 receiver channel 必须带缓冲，容量根据业务容忍丢弃率设定（如
make(chan struct{}, 1)可防瞬时抖动） - 广播时不用
ch 直发，改用 <code>select { case ch 非阻塞发送 - 注册 receiver 时记录创建时间，配合后台 goroutine 定期扫描
lastUsed，超时未读则注销并关闭该 channel - 不要在广播协程里做任何耗时操作（如日志、HTTP 调用），只做纯粹的 channel 复制
广播后怎么确认所有 worker 真正退出
close(done) 只是发信号，不等待执行。若需强一致性退出（比如优雅下线），必须组合 sync.WaitGroup：
- 启动每个 worker 前调用
wg.Add(1) - 每个 worker 在
return前调用wg.Done() - 主 goroutine 调用
close(done)后，立刻wg.Wait()
注意：WaitGroup 的生命周期必须覆盖全部 worker，不能在 close(done) 后才声明 wg，否则存在竞态——worker 可能在 wg.Add 之前就已启动并尝试 Done。
真正难的不是写对这几行代码，而是意识到：广播只是开始，退出同步才是高并发系统里最易出错的一环。没人会盯着 wg.Wait() 超时，但一旦漏掉一个 Done()，整个进程就卡死不动。
