在 Go 并发编程中，done 通道并非冗余，而是确保主 goroutine 等待工作 goroutine 完全执行完毕的关键同步机制；仅依赖 close() 无法保证接收端逻辑已执行完成。
在 go 并发编程中，`done` 通道并非冗余，而是确保主 goroutine 等待工作 goroutine 完全执行完毕的关键同步机制；仅依赖 `close()` 无法保证接收端逻辑已执行完成。
Go 的 goroutine 是轻量级线程，调度由运行时管理，主 goroutine 退出会导致整个程序立即终止——无论其他 goroutine 是否仍在运行。这正是 done 通道存在的根本原因：它提供一种显式、可靠、阻塞式的完成通知方式。
考虑以下典型场景（简化自 Go by Example）：
func main() {
jobs := make(chan int, 5)
done := make(chan bool) // ← 关键同步信号
go func() {
for j := range jobs { // 使用 range 自动检测 channel 关闭
time.Sleep(500 * time.Millisecond) // 模拟耗时处理
fmt.Println("received job", j)
}
fmt.Println("received all jobs")
done <p>若移除 <code>done</code> 通道及 <code> 语句（如原问题中的 Playground 示例），程序行为将<strong>不可预测</strong>：</code></p>
- 在多数本地环境或高负载下，主 goroutine 往往在 worker 刚开始处理第一个 job 时就执行完
close(jobs)和fmt.Println("sent all jobs")，随即退出； - worker goroutine 被强制终止，
"received job X"和"received all jobs"永远不会打印； - 即使偶尔看到输出，也属竞态下的偶然现象，不可靠、不可移植、不可测试。
⚠️ 注意事项：
-
close(ch)仅表示“不再发送”，不等于“已被完全接收”；接收端可能尚未消费完缓冲区内容，更遑论执行后续逻辑。 -
time.Sleep()是错误的同步手段：它既不能保证时序正确性，又降低性能、掩盖设计缺陷。 - 推荐使用
done通道（或sync.WaitGroup、context）实现显式协作式同步，这是 Go “不要通过共享内存来通信，而应通过通信来共享内存”哲学的直接体现。
总结：done 通道不是“为了关闭而存在”，而是为确定性同步而设计——它让主流程能精确知晓并发任务何时真正结束，是构建健壮、可维护 Go 并发程序的基石实践。
