channel 阻塞

Go 里看到 一直没有返回，第一件事不是马上加更多 goroutine，而是确认 ch 是否仍然是 nil。例如 var ch chan int 只声明了一个 channel 类型变量，并没有创建可通信的 channel；从它接收会永久阻塞。

nil channel 永远不会就绪。要让接收继续，通常需要在生命周期合适的位置用 make(chan T) 初始化，并确保发送方持有的是同一个 channel；如果等待必须可退出，就把接收放进带超时或取消信号的 select。

先确认阻塞的是哪一种 channel

channel 的“容量为 0”和“值为 nil”不是同一件事。下面三种写法看起来相近，运行语义却不同：

package main

import "fmt"

func main() {
	var nilCh chan int
	unbuffered := make(chan int)
	closed := make(chan int)
	close(closed) // 关闭后不能再发送，但接收可以立即得到零值和 false

	fmt.Println(nilCh == nil) // 中文注释：声明但未 make，值仍是 nil
	fmt.Println(cap(unbuffered)) // 中文注释：容量为 0，不代表 channel 是 nil
	v, ok := 

nilCh == nil 为真，说明变量没有关联到 channel 对象；unbuffered 的容量虽然也是 0，但它已经由 make 初始化，发送方和接收方同时准备好时可以完成通信；closed 则已经进入关闭状态，后续接收会返回元素类型的零值以及 false。

为什么从 nil channel 接收会一直等

Go 语言规范把 nil channel 定义为永远不会就绪的通信对象。因此下面的接收表达式不会因为“暂时没有值”而稍后恢复，而是没有任何发送、关闭或缓冲状态能够让它变成可接收：

package main

func main() {
	var ch chan int
	v := 

如果这段代码在主 goroutine 中运行，程序会因为所有 goroutine 都无法继续而出现死锁提示；如果它在工作 goroutine 中运行，则更像是“某个任务没有结果”，同时还可能让请求、资源或等待组一直无法收尾。

最小修复是把 make 放在正确的生命周期里

初始化不仅要存在，还要发生在接收开始之前，并把同一个 channel 交给发送方。仅仅在另一个局部变量里调用 make，不会改变原来那个 nil 变量。

package main

import "fmt"

func produce(out chan

这里的 make(chan int) 只是创建未缓冲 channel，不等于“接收一定不会阻塞”。它要求发送方和接收方在通信点相遇；如果发送方没有启动、发送到了另一个 channel，或者发送方提前退出，接收仍然可能等待。排查时应同时打印或断点确认 channel 是否为 nil，以及生产者和消费者是否使用同一个变量来源。

用 select 给等待加上可退出条件

当 channel 来自可选依赖、后台任务或外部输入时，直接写 会把等待边界交给 channel 本身。更稳妥的做法是同时监听取消信号或超时：

package main

import (
	"context"
	"fmt"
	"time"
)

func wait(ctx context.Context, ch 

如果传入的 ch 是 nil，上面的业务 case 会永久不可选，但取消或超时 case 仍然可以继续。这是 nil channel 在 select 中有用的一面：它可以被当作“暂时禁用这一通信分支”的状态。不过，若整个 select 只有 nil case 且没有 default 或其他可就绪 case，它仍会永久阻塞。

关闭 channel 不等于初始化 channel

关闭只能作用于已经存在的 channel。对 nil channel 调用 close 会触发运行时 panic，因此不能把“接收一直阻塞”简单改成“先关闭它”：

package main

func main() {
	var ch chan int
	close(ch) // 中文注释：ch 仍为 nil，关闭 nil channel 会 panic
}

正确的关闭边界通常由发送方负责：发送方确认不会再发送后关闭 channel，接收方用双返回值形式区分有效值与关闭状态。若 channel 只是为了传递一次结果，也可以结合 context 或明确的错误返回设计，避免把关闭动作当成初始化或超时机制。

排查 channel 阻塞的速查表

常见延伸问题

nil channel 能不能用在 select 里？

可以。它对应的 case 永远不会被选中，常用于按条件启用或禁用一条通信分支，但必须确保 select 还有其他可继续条件。

把 channel 改成带缓冲就能解决 nil 阻塞吗？

不能。缓冲区大小只影响已经由 make 创建的 channel；nil channel 没有通信缓冲，也不会因为指定了容量而自动初始化。

为什么 len(ch) 不能用来判断是否初始化？

nil channel 的长度和容量都可以是 0，未缓冲但已初始化的 channel 容量也可以是 0。要判断初始化状态，直接比较 ch == nil。