在 Go 中，当并发启动未知数量的任务并将结果写入无缓冲或带缓冲通道时，若未正确关闭通道，主 goroutine 在 for range 读取时会永久阻塞——这种“隐式死锁”无法被 runtime 检测，尤其在长期运行的服务（如 Web 服务器）中极易导致服务挂起。
在 go 中，当并发启动未知数量的任务并将结果写入无缓冲或带缓冲通道时，若未正确关闭通道，主 goroutine 在 `for range` 读取时会永久阻塞——这种“隐式死锁”无法被 runtime 检测，尤其在长期运行的服务（如 web 服务器）中极易导致服务挂起。
要可靠解决该问题，核心原则是：通道的关闭时机必须与所有写操作的完成严格同步，且不能由任意写 goroutine 主动关闭（避免竞态），也不能由读端单方面决定（缺乏完成信号）。最简洁、标准且符合 Go 并发惯用法的方案是结合 sync.WaitGroup 与异步关闭机制。
以下为修复后的完整示例：
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
// 启动不确定数量的 goroutine，并为每个任务注册 WaitGroup 计数
n := rand.Intn(1<p>✅ <strong>关键要点说明：</strong> </p>
- WaitGroup 承担“任务完成协调者”角色：Add() 在启动前调用（避免漏计），Done() 在任务结束时调用（推荐用 defer 保证执行）。
- 关闭通道的操作被移至独立 goroutine 中，由 wg.Wait() 阻塞直到所有写操作完成，从而彻底消除竞态和提前关闭风险。
- for range ch 语义明确：仅在通道关闭且缓冲区为空时退出循环，无需额外计数或超时逻辑。
- ⚠️ 注意：切勿在多个 goroutine 中调用 close(ch)，否则 panic；也禁止在写操作未完成前关闭通道（数据丢失或 panic）。
在 Web 服务器等生产场景中，还可进一步增强健壮性：例如为 wg.Wait() 添加上下文超时（context.WithTimeout），防止某任务异常卡死导致通道永不关闭；或使用 select + default 实现非阻塞读取配合重试逻辑。但对绝大多数场景，WaitGroup + 异步 close 已是最轻量、最可靠、最符合 Go idioms 的解决方案。
