在并发程序中，当向通道写入未知数量的任务结果且无法提前关闭通道时，直接使用 for range 读取会导致永久阻塞——Go 运行时无法检测此类“隐式死锁”，尤其在长期运行的服务（如 Web 服务器）中极易引发资源挂起。
在并发程序中，当向通道写入未知数量的任务结果且无法提前关闭通道时，直接使用 `for range` 读取会导致永久阻塞——go 运行时无法检测此类“隐式死锁”，尤其在长期运行的服务（如 web 服务器）中极易引发资源挂起。
要可靠解决这一问题，核心在于明确通道生命周期：必须确保所有写操作完成后，才关闭通道，从而让 for range 正常退出。但由于任务数量动态生成、写入由多个 Goroutine 异步完成，无法在主流程中直接调用 close(results) ——过早关闭会 panic，过晚则导致读端永久等待。
推荐方案是结合 sync.WaitGroup 与异步关闭机制：
- 使用 WaitGroup 精确追踪待完成的 Goroutine 数量；
- 在所有写操作结束后，在独立 Goroutine 中调用 close()，避免阻塞主逻辑；
- 主 goroutine 可安全使用 for range results 持续消费，直到通道关闭自动退出。
以下是修复后的完整示例：
package main
import (
"fmt"
"math/rand"
"sync"
"time"
)
func main() {
rand.Seed(time.Now().UTC().UnixNano())
results := make(chan int, 100)
var wg sync.WaitGroup
// 启动不定数量的任务，并同步计数
n := rand.Intn(1<p>✅ <strong>关键要点说明：</strong> </p>
- wg.Add(1) 必须在 go 语句之前调用，避免竞态；
- defer wg.Done() 是惯用写法，确保即使发生 panic 也能正确计数；
- close(results) 只能由写端调用一次，且必须在所有写操作完成后；
- 不要将 close() 放在主 goroutine 中紧随 for 启动之后——这会因未等待写入完成而引发 panic 或数据丢失；
- 若需支持取消或超时（如 Web 请求上下文），可进一步结合 context.Context 控制整个流程生命周期。
该模式是 Go 并发编程中的标准实践，广泛应用于服务端管道（pipeline）、批量任务调度及异步结果聚合等场景，兼顾安全性、可读性与可维护性。
