本文探讨在 go 并发编程中，使用无缓冲通道（sync channels）作为同步机制的实践价值，分析其与 sync.waitgroup 的异同，指出适用场景、潜在陷阱及工程权衡要点。
本文探讨在 go 并发编程中，使用无缓冲通道（sync channels）作为同步机制的实践价值，分析其与 sync.waitgroup 的异同，指出适用场景、潜在陷阱及工程权衡要点。
在 Go 语言中，无缓冲通道（make(chan T)）天然具备同步语义——发送操作会阻塞，直到有协程执行对应接收；反之亦然。这种“配对阻塞”特性使其可被直接用作轻量级同步原语，尤其适用于等待固定数量协程完成并获取结果的场景。如下示例即典型用法：
func main() {
chan1, chan2, chan3 := make(chan bool), make(chan bool), make(chan bool)
go fn(chan1)
go fn(chan2)
go fn(chan3)
res1, res2, res3 := <-chan1, <-chan2, <-chan3 // 阻塞等待全部完成
}该模式简洁直观：每个 goroutine 执行完毕后向专属通道发送信号（如 true 或实际结果），主 goroutine 通过接收操作统一汇合。它无需额外状态管理，也避免了 WaitGroup.Add() 调用时机错误的风险（如漏调、多调、提前调用）。
然而，需警惕几个关键约束与权衡点：
- 严格配对要求：每个发送必须有且仅有一个对应接收。若某 goroutine panic 或提前退出未发送，主 goroutine 将永久阻塞在 <-chanX 上（即所谓“goroutine 泄漏”）。而 WaitGroup 具备显式计数和超时配合能力，更易做容错处理。
- 无法动态扩展：通道数量需编译期确定（如上例硬编码为 3 个）。若任务数来自运行时输入（如 for i := range items { go worker(ch) }），则需动态创建通道切片或改用其他模式（如单个带缓冲通道聚合结果）。
- 语义清晰性取决于上下文：当通道同时承载数据传递 + 同步信号（如 chan Result）时，代码意图明确；但若仅用于 chan struct{} 类型的纯同步，则 WaitGroup 的 Done() 更直白表达“工作结束”，可读性反而更高。
- 资源开销差异微乎其微：通道底层涉及 goroutine 调度器参与，WaitGroup 则是原子计数，但二者在常规并发规模下性能差异可忽略。真正影响系统表现的是设计合理性，而非原语选择本身。
✅ 推荐使用无缓冲通道同步的典型场景：
- 启动 N 个独立 worker，每个返回一个确定结果（如 RPC 响应、计算值）；
- 需自然支持“带结果的等待”，且结果类型统一或可泛型化；
- 已存在基于 channel 的通信架构（如 select 多路复用、abort channel），将同步融入同一抽象层可提升一致性。
❌ 建议优先考虑 sync.WaitGroup 的情况：
- 仅需“等待完成”，不关心返回值；
- 任务数动态变化，且结果无需按启动顺序收集；
- 需要配合 context.WithTimeout 实现超时控制（可结合 select + time.After，但 WaitGroup 更易组合）；
- 团队规范强调显式生命周期管理，或代码审查偏好更“面向意图”的 API。
总结而言，无缓冲通道不是“替代” WaitGroup 的方案，而是不同抽象层级上的互补工具：前者是通信原语的同步副产品，后者是专为协作等待设计的同步原语。选择依据应是代码想表达的语义——若“等待并取回结果”是核心诉求，通道天然契合；若“确保所有任务抵达终点”是唯一目标，WaitGroup 更精准。实践中，二者甚至可协同使用（例如用 WaitGroup 管理生命周期，用通道传递结果），关键在于保持接口语义一致、错误处理完备、资源释放明确。
