最安全是因为它天然杜绝值误用、语义模糊和零值歧义；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 <h3>关闭 channel 后再读，为什么有时拿到 <code>struct{}{}</code> 有时 panic？</h3><p>关键看怎么读：</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/learn/7564" title="使用Go语言搭建家庭相册系统-相关课件"><img
src="https://img.php.cn/upload/webcode/000/000/164/636a2b4d84031727.png" alt="使用Go语言搭建家庭相册系统-相关课件" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/learn/7564" title="使用Go语言搭建家庭相册系统-相关课件" class="overflowclass">使用Go语言搭建家庭相册系统-相关课件</a>
<p class="overflowclass">使用Go语言搭建家庭相册系统-相关课件</p>
</div>
<a rel="nofollow" href="/xiazai/learn/7564" title="使用Go语言搭建家庭相册系统-相关课件" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
（无判断）：通道关闭后立即返回 <code>struct{}{}，不 panic，但你无法区分是“真信号”还是“已关闭”val, ok := ：<code>ok == false表示通道已关闭，此时val是零值（即struct{}{}），安全- 对已关闭的
ch执行ch ：直接 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 判断就直接接收会掩盖关闭事实。
