本文详解 go 中 “all goroutines are asleep - deadlock” 错误的成因与修复，聚焦于无限 `select` 循环导致主 goroutine 永久阻塞的问题，并提供安全、可预测的通道消费方案。
你的程序崩溃并输出 fatal error: all goroutines are asleep - deadlock!，根本原因在于：主 goroutine 在一个无退出条件的 for { select { ... } } 无限循环中永久阻塞，而所有工作 goroutine 已全部执行完毕并退出，导致整个程序无任何活跃 goroutine 可运行——即死锁。
具体分析如下：
- 你启动了 5 个 goroutine（对应 file_names 的 5 个文件），每个 goroutine 调用 proccesFileName，并在处理完所有缩略图（6 张）后，向 c 或 ce 发送若干消息（共约 30 条）；
- 然而，主 goroutine 的 for { select { ... } } 没有终止逻辑：它会一直等待从 c 或 ce 接收消息，但一旦所有工作 goroutine 执行完毕、通道不再有新数据写入，且你又未关闭通道，select 就永远阻塞；
- 更严重的是：proccesFileName 中存在一个隐蔽 bug —— defer file.Close() 和 defer out.Close() 的位置错误（defer 在函数开头定义，但 file/out 可能为 nil，且 defer 不会在 return 后立即执行），但这不是死锁主因；真正致命的是主循环无法感知“所有任务已完成”这一状态。
✅ 正确做法：明确知道需接收的消息总数，并据此控制循环次数。由于每个文件生成 6 张缩略图（scales 长度为 6），5 个文件共发送最多 5 × 6 = 30 条成功消息（或若干错误），因此可精确循环 30 次：
// 替换原无限循环
for i := 0; i < len(file_names)*len([]float32{1.0, 0.8, 0.6, 0.5, 0.25, 0.01}); i++ {
select {
case str := <-c:
fmt.Println(str)
case err := <-ce:
fmt.Println("ERROR:", err)
}
}更健壮、推荐的方案是使用 sync.WaitGroup + 关闭通道，实现优雅等待与信号通知：
func main() {
runtime.GOMAXPROCS(4)
file_names := make([]string, 5)
for i := 1; i < 6; i++ {
file_names[i-1] = fmt.Sprintf("%v", i)
}
c := make(chan string, 32) // 建议设缓冲，避免 sender 阻塞
ce := make(chan error, 8)
var wg sync.WaitGroup
wg.Add(len(file_names))
for _, filename := range file_names {
go func(fn string) {
defer wg.Done()
proccesFileName(fn, c, ce)
}(filename) // 注意：必须传参，避免闭包捕获循环变量
}
// 启动 goroutine 关闭通道（在所有 worker 完成后）
go func() {
wg.Wait()
close(c)
close(ce)
}()
// 安全消费：range channel 自动在关闭后退出
for str := range c {
fmt.Println(str)
}
for err := range ce {
fmt.Println("ERROR:", err)
}
}⚠️ 关键注意事项：
- 闭包陷阱：原代码 go func() { proccesFileName(filename, ...) }() 中 filename 是循环变量，所有 goroutine 共享同一地址，最终可能全处理最后一个值。务必通过 go func(fn string){...}(filename) 显式传参。
- 通道未关闭 + 无限等待 = 必然死锁：range 或 select 永不退出，除非通道被关闭。
- defer 位置错误：defer file.Close() 应在 os.Open 成功后立即调用（如 if err == nil { defer file.Close() }），否则 file 为 nil 时 defer file.Close() 会 panic。
- 缓冲通道提升性能：为 c/ce 设置合理缓冲（如 make(chan string, 32)），避免 sender 因 receiver 暂未读取而阻塞。
总结：Go 的死锁检测非常严格。避免 all goroutines are asleep 的核心原则是——确保至少有一个 goroutine 始终处于可运行状态，或通过关闭通道+有限循环/range 明确结束等待。优先使用 sync.WaitGroup 协调任务生命周期，并配合已关闭的通道进行消费，这是生产环境最可靠、最易维护的模式。
