go 中没有内置“垃圾通道”，但可通过非阻塞发送、关闭通道或可变参数设计实现零开销的可选完成通知，避免阻塞、内存泄漏和冗余 goroutine。
go 中没有内置“垃圾通道”，但可通过非阻塞发送、关闭通道或可变参数设计实现零开销的可选完成通知，避免阻塞、内存泄漏和冗余 goroutine。
在 Go 并发编程中，done 通道常用于异步任务完成通知（如测试中等待协程结束）。但当调用方不关心通知时，传入一个“空”或“哑”通道的需求便浮现出来——既不能传 nil（会导致发送永久阻塞），也不应启动专用消费者 goroutine（造成资源浪费和生命周期管理复杂化）。
推荐方案：关闭通道而非发送值
最符合 Go 惯例的做法是关闭通道而非向其发送信号。关闭操作本身是非阻塞的（只要通道非 nil），且所有已阻塞的 接收操作会立即返回零值（对 <code>chan struct{} 即为 struct{}{}），天然支持“广播式”唤醒。更重要的是，chan struct{} 零内存占用，语义更清晰（仅表“完成事件”，无需携带数据）。
func myFunc(foo int, done chan<p>调用方式简洁安全：</p><pre class="brush:php;toolbar:false;">ch := make(chan struct{})
myFunc(42, ch)
<p><strong>进阶：使用可变参数提升灵活性</strong><br>
若需同时通知多个监听者，或完全省略通道参数，可采用 <code>...chan 形式：</code></p><pre class="brush:php;toolbar:false;">func myFunc(foo int, done ...chan<p><strong>为什么不推荐“非阻塞发送”或“垃圾通道”？</strong><br>
虽然 <code>select { case done 可规避阻塞，但它掩盖了设计问题：发送值意味着接收方必须消费，而多数场景只需“事件发生”信号。若接收端未及时读取，缓冲区满后仍会阻塞；若使用无缓冲通道，则 <code>default</code> 分支永远生效，通知失效。此外，维护一个持续消费的 goroutine（如 <code>go func() { for range ch {} }()</code>）违背了“少即是多”的 Go 哲学，引入不必要的调度开销与潜在泄漏风险。</code></p><p><strong>关键注意事项</strong> </p>
- ✅ 始终对
done做nil检查后再操作（关闭nil通道会 panic）； - ✅ 优先选用
chan，明确只写、零开销； - ❌ 避免向通道发送任意值（如
bool）作为完成信号——语义模糊且易引发类型误用； - ⚠️ 若必须保留发送模式（如兼容旧接口），请确保通道有足够缓冲或接收方就绪，否则
select+default仅为临时规避，非根本解法。
综上，关闭通道 + 显式 nil 检查 + 可变参数构成了一套轻量、安全、符合 Go 风格的可选完成通知方案，兼顾测试友好性与生产健壮性。
