最安全是因为它天然杜绝值误用、语义模糊和零值歧义；chan bool易混淆false含义，chan int语义不清且浪费内存（bool占1字节、int占8字节），而struct{}{}占0字节、行为确定。
用 chan struct{} 做信号传递最安全，不是因为“轻量”，而是它天然杜绝了值误用、语义模糊和零值歧义——发送端只发 struct{}{}，接收端只关心“有没有”，不关心“是什么”。
为什么不能用 chan bool 或 chan int 传信号？
看似能用，但埋了三个坑：
-
chan bool：接收端可能误判false是“信号来了”还是“通道关闭后读到的零值”，尤其配合select+default时逻辑易错 -
chan int：发送0还是1？语义不清；若 sender 忘记发、receiver 多读一次，就卡死或 panic - 两者都浪费内存：
bool占 1 字节，int通常占 8 字节，而struct{}{}占 0 字节，且len(ch)和cap(ch)行为一致
select 配 case 怎么防卡死？
纯阻塞接收 会永久挂起，除非 sender 确保一定发。真实场景中必须加兜底：
- 超时控制：用
time.After配合select，避免等不到信号就僵住 - 非阻塞尝试：加
default分支，做轮询或 fallback 逻辑 - 别在同一个 goroutine 里先发后收：这等于自己锁自己，必死锁
示例：
select {
case <-done:
fmt.Println("收到完成信号")
case <-time.After(5 * time.Second):
fmt.Println("超时，强制退出")
}关闭 channel 后再读，为什么有时拿到 struct{}{} 有时 panic？
关键看怎么读：
-
<-ch（无判断）：通道关闭后立即返回struct{}{}，不 panic，但你无法区分是“真信号”还是“已关闭” -
val, ok := <-ch：ok == false表示通道已关闭，此时val是零值（即struct{}{}），安全 - 对已关闭的
ch执行ch <- struct{}{}：直接 panic: send on closed channel
所以信号 channel 的 sender 必须负责关闭，receiver 绝不能关；且 receiver 应优先用带 ok 判断的接收模式。
多个信号源怎么合并？用 nil channel 技巧
当要等 c1 和 c2 都就绪才继续，但又不想写复杂状态机，就利用 nil channel 在 select 中自动失效的特性：
- 初始两个非 nil channel
- 任一 signal 到达后，把它设为
nil，下次select就跳过该 case - 全为
nil时说明所有信号已收完
这是 Go 运行时对 select 的隐式优化，不用额外锁或计数器。
真正容易被忽略的点是：信号 channel 的生命周期管理。它不像数据流 channel 那样有明确的“生产-消费”边界；一个 done 通道可能被多个 goroutine 监听，但只能由唯一 owner 关闭——漏关会卡死，多关会 panic，没做 ok 判断就直接接收会掩盖关闭事实。
