Go 中无法直接传入“垃圾通道”丢弃通知，但可通过非阻塞发送、关闭通道或变参设计实现零开销、无竞态的可选完成通知机制。推荐优先使用 close() 配合 chan
go 中无法直接传入“垃圾通道”丢弃通知，但可通过非阻塞发送、关闭通道或变参设计实现零开销、无竞态的可选完成通知机制。推荐优先使用 `close()` 配合 `chan
在 Go 并发编程中，done 通道常用于异步任务完成通知（如协程退出信号），但当调用方不关心完成状态时，传入一个“占位通道”以避免修改函数签名成为常见需求。关键误区是试图传入 nil 通道或启动消耗 goroutine 的“垃圾通道”——前者会导致发送永久阻塞，后者引入不必要的调度开销和资源泄漏风险。
✅ 推荐方案：关闭通道（close）而非发送值
最符合 Go 习惯的方式是用关闭代替发送。因为：
- 关闭
chan 是零值、零分配操作； - 所有接收端（
）会立即返回零值（<code>struct{}{}），无需逐个消费； - 发送方永不阻塞（即使无人接收）；
- 语义更准确：
close(done)表示“任务已终结”，而非“发一个完成事件”。
func myFunc(foo int, done chan<p>调用方式简洁自然：</p><pre class="brush:php;toolbar:false;">// 不需要通知 → 传 nil
myFunc(42, nil)
// 需要通知 → 传具体通道
done := make(chan struct{})
go myFunc(42, done)
<h3>⚠️ 注意事项</h3>
-
切勿关闭
nil通道：close(nil)会 panic，因此必须显式判空； -
类型选择
chan：比chan bool更轻量（0 字节），且单向通道明确表达“只用于通知”意图； -
避免
select { case done：虽可非阻塞发送，但需每次手动写select，易遗漏；且若通道已关闭，发送会 panic —— 而close()本身对已关闭通道是安全的（无效果）。
? 进阶：变参支持多通道与完全省略
进一步提升灵活性，可将 done 设计为变参，支持零个、一个或多个通知通道：
Send email using MailChannels Email API
下载
通过 MailChannels Email API 发送邮件，并将已签名的投递事件 Webhook 接收至 Clawdbot (Moltbot)。
func myFunc(foo int, done ...chan<p>调用示例：</p><pre class="brush:php;toolbar:false;">myFunc(1) // 无通知 myFunc(2, ch1) // 单通道通知 myFunc(3, ch2, ch3, ch4) // 多通道同步通知（全部关闭）
此设计彻底消除了“垃圾通道”的概念：nil 是合法、安全、零成本的“无通知”标识；close() 是原子、高效、语义完备的通知机制；变参则让 API 同时兼容简洁性与扩展性——这正是 Go 式接口设计的典型范式。
