Go 中如何准确判断输出通道已关闭并完成所有数据接收

在 go 并发编程中，当多个 worker 协程向同一输出通道（output channel）发送结果时，主协程需可靠感知“所有任务已完成”，从而安全退出 `range` 循环。推荐使用 `sync.waitgroup` 配合通道关闭机制实现同步，避免死锁或数据丢失。

在典型的生产者-消费者并发模型中，我们常启动多个 worker 协程从输入通道读取任务、处理后将结果写入共享的输出通道。但问题在于：输出通道本身不会自动关闭——只要还有 worker 在运行，就无法确定是否还有未发送的结果；而过早关闭通道会导致 panic，不关闭又会使 for range 永远阻塞。

最佳实践是引入 sync.WaitGroup 作为协作式完成信号：它提供线程安全的计数器，允许主协程等待所有 worker 显式声明“我已完成”。关键设计原则是：

• 计数与生命周期对齐：每启动一个 worker，调用 wg.Add(1)；每个 worker 在彻底结束前（即完成所有输出后）调用 wg.Done()；
• 由单一协程负责关闭通道：另启一个协程调用 wg.Wait()，待全部 worker 完成后立即 close(outchan)；
• 利用 range 的语义优势：for v := range outchan 会在通道关闭且缓冲区清空后自然退出，无需额外控制逻辑。

以下是完整可运行示例（以字符串处理为例）：

package main

import (
    "fmt"
    "sync"
    "time"
)

func worker(wg *sync.WaitGroup, in <-chan string, out chan<- string) {
    defer wg.Done() // 确保无论何种路径退出都调用 Done()

    for job := range in {
        // 模拟耗时处理
        time.Sleep(100 * time.Millisecond)
        result := fmt.Sprintf("processed: %s", job)
        out <- result
    }
}

func main() {
    const numWorkers = 3
    in := make(chan string, 10)
    out := make(chan string, 10)

    var wg sync.WaitGroup

    // 启动 workers
    for i := 0; i < numWorkers; i++ {
        wg.Add(1)
        go worker(&wg, in, out)
    }

    // 启动关闭协程：等待所有 worker 结束后关闭输出通道
    go func() {
        wg.Wait()
        close(out)
    }()

    // 发送任务（模拟生产者）
    go func() {
        for _, task := range []string{"A", "B", "C", "D", "E"} {
            in <- task
        }
        close(in) // 输入通道也可适时关闭（worker 中 range 会自动退出）
    }()

    // 主协程消费结果 —— 自动在 out 关闭后终止
    for result := range out {
        fmt.Println(result)
    }
    fmt.Println("All results processed. Program finished.")
}

✅ 注意事项与最佳实践：

• wg.Add() 必须在 go 语句之前调用（避免竞态），且不能在 worker 内部调用 Add()；
• defer wg.Done() 是惯用写法，确保异常或提前返回时仍能正确减计数；
• 输出通道应为无缓冲或合理缓冲，避免因缓冲区满导致 worker 阻塞而无法执行 Done()；
• 不要从多个 goroutine 同时关闭同一通道（panic），务必保证 close(out) 仅执行一次；
• 若 worker 还需响应取消信号（如 context.Context），应在 range in 循环中加入 select 判断，但 wg.Done() 仍需放在最终退出路径上。

通过 WaitGroup + close(channel) 组合，你获得了一种简洁、可靠、符合 Go 信道哲学的完成同步方案——既避免了轮询和超时陷阱，也无需引入复杂的状态机，真正践行了 “Don’t communicate by sharing memory, share memory by communicating.”