本文详解 Go 程序中因通道未关闭导致的 goroutine 死锁问题，通过分析典型代码示例，说明为何接收端会永久阻塞，并给出安全关闭通道、正确使用 ok 检测的完整实践方案。
本文详解 go 程序中因通道未关闭导致的 goroutine 死锁问题，通过分析典型代码示例，说明为何接收端会永久阻塞，并给出安全关闭通道、正确使用 `ok` 检测的完整实践方案。
在 Go 并发编程中，死锁（deadlock）是最常见也最需警惕的运行时错误之一。它发生于所有 goroutine 同时被阻塞且无法继续执行的状态——此时 Go 运行时会主动 panic 并终止程序，提示 fatal error: all goroutines are asleep - deadlock!。
上述代码的问题核心在于：发送端 goroutine 发送完 10 个整数后自然退出，但并未关闭通道；而主 goroutine 的接收循环 for { 在读取完全部 10 个值后，仍试图从已无发送者的通道中接收数据，从而无限阻塞在 <code> 操作上。由于此时仅剩主 goroutine 在运行且处于阻塞状态，Go 调度器判定程序已“完全停滞”，触发死锁检测并崩溃。
关键修正点有二：
-
由发送方负责关闭通道：关闭操作应发生在发送逻辑完成后，且只能由发送方调用（多次关闭会 panic）。修改后的发送 goroutine 如下：
go func() { for i := 0; i < 10; i++ { ch <- i } close(ch) // ✅ 发送完毕后立即关闭 }() -
接收端依赖
ok判断通道关闭状态：在已关闭的无缓冲通道上会立即返回零值（<code>0）和false，此时应退出循环：for { if num, ok := <-ch; !ok { break // ✅ 收到 false 表明通道已关闭，安全退出 } else { fmt.Printf("%d\n", num) } }
⚠️ 注意事项：
- 删除原代码末尾的
close(ch)—— 主 goroutine 不是发送方，无权关闭通道，且此时通道尚未关闭，该调用本身就会 panic。 - 不要移除
time.Sleep后的close(ch)—— 它已失效且危险，必须彻底删除。 - 若使用带缓冲通道（如
ch := make(chan int, 10)），虽可避免立即阻塞，但不关闭通道仍会导致接收循环无法感知结束，因此关闭仍是必需步骤。 - 更推荐使用
for range语法简化接收逻辑（自动处理关闭）：for num := range ch { // ✅ 等价于 ok-check 循环，更简洁 fmt.Printf("%d\n", num) }
总结：Go 中通道的生命周期管理遵循“谁发送，谁关闭”原则；接收方须通过 ok 标志或 range 语句响应关闭信号。忽视这一契约，轻则逻辑卡死，重则触发全局死锁——这是每位 Go 开发者必须内化的并发基本功。
