用chan struct{}是因为零内存开销且语义明确：struct{}占0字节，而bool占1字节、int占8字节；数百goroutine下可节省数十KB内存；其零值唯一、地址相同，支持安全比较；编译器专门优化，发送/接收无额外开销；见名知意，表明仅作信号传递。
无缓冲 chan struct{} 是 go 中实现 goroutine 间信号同步最轻量、最可靠的方式，比用 sync.waitgroup 或 sync.mutex 更贴近 csp 哲学，且零内存分配、无锁、无竞争。
为什么用 chan struct{} 而不是 chan bool 或 chan int
信号同步不需要携带任何数据，只关心“事件是否发生”。struct{} 占用 0 字节，发送/接收不触发内存拷贝；而 bool 或 int 至少占 1 或 8 字节，虽小但非必要。更重要的是，编译器对 chan struct{} 的优化更彻底——例如在 select 中的默认分支判断、关闭后接收行为都更可预测。
常见误用：var done = make(chan bool)，看似无害，但一旦写成 done 后忘记关闭或未被消费，就可能造成 goroutine 泄漏。
-
chan struct{}明确语义：纯信号，不可误读为“带状态的数据” - 关闭后
立即返回（<code>ok == false），适合做终止通知 - 无法意外写入非零值（
struct{}只有一个零值）
select + chan struct{} 实现超时与取消的惯用写法
单个信号通道配合 select 可以优雅处理超时、中断、条件等待等场景，避免轮询或复杂状态机。
典型模式：
done := make(chan struct{})
timeout := time.After(5 * time.Second)
<p>go func() {
// 模拟耗时操作
time.Sleep(3 * time.Second)
close(done) // 发送完成信号
}()</p><p>select {
case <-done:
fmt.Println("task finished")
case <-timeout:
fmt.Println("task timed out")
}注意点：
- 不要用
done 替代 <code>close(done)——前者需配对接收，后者可被多次接收（只要未关闭前没人收，关闭后所有立即返回） -
time.After在长时间未触发时会泄漏 timer，高频率调用应改用time.NewTimer并显式Stop() - 若需复用
done通道，必须重建；已关闭的chan struct{}无法重开
多 goroutine 协同退出时的关闭时机陷阱
生产代码中常犯的错误是：由消费者关闭信号通道，但生产者仍在尝试发送 —— 导致 panic: “send on closed channel”。正确做法永远是**发送方（生产者）决定何时停止，并负责关闭通道**。
例如一个日志采集协程向信号通道广播“已退出”：
done := make(chan struct{})
go func() {
defer close(done) // 确保退出时关闭
for range ticker.C {
if err := sendLog(); err != nil {
return
}
}
}()
<p>// 主协程等待
<-done关键约束：
- 一个通道只应由一个 goroutine 关闭，否则可能 panic（
close多次） - 若存在多个生产者，需用
sync.WaitGroup+ 最后一个完成者关闭，或改用sync.Once包裹close - 接收方绝不能假设
一定成功：需用 <code>v, ok := 判断是否因关闭而返回
真正容易被忽略的是：信号通道本身不传递上下文语义。比如 done 关闭只表示“某事结束了”，但不说明是成功、失败还是被取消。需要额外状态（如 error channel 或 context）才能区分原因。别指望一个 chan struct{} 承担太多责任。
