在 Go 中，当并发启动未知数量的任务并将结果写入无缓冲或带缓冲通道时，若未正确关闭通道，主 goroutine 在 for range 读取时会永久阻塞，导致难以检测的“隐式死锁”——尤其在 Web 服务器等长期运行程序中。
在 go 中，当并发启动未知数量的任务并将结果写入无缓冲或带缓冲通道时，若未正确关闭通道，主 goroutine 在 `for range` 读取时会永久阻塞，导致难以检测的“隐式死锁”——尤其在 web 服务器等长期运行程序中。
这类问题的核心在于：for range ch 语义要求通道被显式关闭才会退出循环；而若所有写操作未完成就关闭通道，会导致数据丢失；若永远不关闭，则循环永不终止。在简单命令行程序中，Go 运行时能检测到所有 goroutine 休眠并 panic 报错（fatal error: all goroutines are asleep - deadlock），但在 Web 服务等存在长期存活 goroutine（如心跳、日志轮转、定时任务）的场景下，运行时无法判定逻辑死锁，程序将静默卡死。
解决的关键是分离“写完成通知”与“读取逻辑”，使用 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
// 启动不确定数量的任务，每个任务完成后标记完成
n := rand.Intn(1<p>✅ <strong>关键要点说明：</strong> </p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/ai/818" title="Genesis"><img
src="https://img.php.cn/upload/ai_manual/000/000/000/175679975971759.png" alt="Genesis" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/ai/818" title="Genesis" class="overflowclass">Genesis</a>
<p class="overflowclass">Genesis是一款面向机器人、具身智能和物理 AI 研究的仿真与数据生成平台。</p>
</div>
<a rel="nofollow" href="/ai/818" title="Genesis" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
- wg.Add(1) 必须在 goroutine 启动前调用，避免竞态；
- defer wg.Done() 放在 goroutine 内部最外层，保障异常路径也能释放计数；
- 关闭通道的操作必须由单一 goroutine 执行，且仅在 wg.Wait() 返回后进行——这是保证“所有写已完成”的唯一可靠方式；
- 通道容量（如 make(chan int, 100)）仅影响缓冲，不改变关闭逻辑；即使使用无缓冲通道，本方案同样适用；
- 切勿在写 goroutine 中直接 close(ch) —— 多个 goroutine 关闭同一通道会 panic。
⚠️ 注意事项：
- 若任务可能失败（如网络超时、panic），需配合 recover 或错误通道传递失败信号，否则 wg.Wait() 会永远等待；
- 在真实 Web 服务中，建议将此模式封装为可复用的 RunTasksAndWait 工具函数，并集成上下文（context.Context）支持取消；
- 避免在 for range 循环内执行耗时操作（如 DB 查询），否则会阻塞后续结果消费——可考虑将结果转发至新 channel 并并行处理。
通过 WaitGroup + close 的组合，我们实现了写端完成感知与读端优雅退出的解耦，彻底规避了隐式死锁风险，使并发任务结果收集既健壮又符合 Go 的并发哲学。
