Go channel nil 发送为什么会永久阻塞

如果日志停在 ch ，goroutine 既没有继续执行，也没有像“向已关闭 channel 发送”那样立即 panic，先检查 ch 是否为 nil。Go 语言规范规定：nil channel 永远不会处于通信就绪状态，因此向它发送会永久阻塞；只有重新给它赋一个可用 channel，或让这条发送分支具备可控退出条件，问题才会消失。

官方地址：https://go.dev/

卡住的现场：发送表达式拿到的是 nil channel

最小的风险写法通常不是复杂并发代码，而是一个看起来很普通的字段或返回值：

package main

func main() {
	var ch chan int // 中文说明：只声明类型，不会分配可通信的 channel
	ch 

这里不会因为值 1 有问题而失败，真正的目标对象是 nil。排查时先看发送点，再沿着变量的来源向上追：它是局部变量、结构体字段、函数返回值，还是接口中取出的 channel？如果没有看到 make(chan int) 或等价的初始化，就不要把“声明成功”当成“通信准备完成”。

生产代码中还要注意 goroutine 的启动顺序。构造函数返回了一个带 nil 字段的对象，后台任务马上读取该字段，发送就可能在初始化补丁到达之前永久停住。这个时间差会让问题看起来像偶发卡顿，实际上根因仍是赋值路径不完整。

为什么 nil channel 不会进入发送就绪状态

channel 的通信条件由 channel 的状态决定。未缓冲 channel 需要发送方和接收方同时准备好；带缓冲 channel 需要缓冲区有空间；nil channel 没有可用的通信队列，因此永远不会满足发送条件。已关闭 channel 则不同：它已经进入终止状态，继续发送会直接触发 panic。

因此，看到“发送卡住”时不要先加一个更大的 buffer。扩大容量只能改变已初始化 channel 的等待时间，不能把 nil channel 变成可通信对象；而把 close 延后也不能修复初始化遗漏。

沿 select 和上游赋值路径排查真正的 nil 来源

如果发送位于 select 中，nil channel 对应的 case 会被视为永远不可选择。它不会让 select 进入忙等，但如果所有其他 case 也不可用，整个 select 仍会等待。可以按下面的顺序检查：

1. 在进入发送函数时记录 channel 是否为 nil，先证明问题发生在调用边界，而不是接收端。
2. 查看构造函数、配置分支和错误返回，确认每条成功路径都给 channel 赋值。
3. 检查接口、闭包和结构体复制，避免初始化了一个对象，却把另一个仍为 nil 的副本传入 goroutine。
4. 检查 select 是否故意把 nil 作为“暂时禁用分支”的开关；如果是设计，就必须保留其他可退出分支。

func send(ctx context.Context, ch chan

这个函数只能解决“等待可取消”，不能替 nil channel 自动初始化。传入 nil 时，发送 case 不会就绪，只有 ctx.Done() 能让调用返回。所以排查结果要写清楚：是 channel 应该由调用者创建却漏了，还是这个参数本来就允许暂时关闭通信。

修复时要把初始化和退出控制放在同一条边界上

如果 channel 是对象的必需能力，就在构造阶段创建，并让对象在发布给其他 goroutine 前完成初始化：

type Worker struct {
	jobs chan int
}

func NewWorker() *Worker {
	return &Worker{
		jobs: make(chan int, 8), // 中文说明：缓冲容量属于通信策略，不能省略初始化
	}
}

如果 channel 是可选能力，可以用局部变量控制 select 分支，但不要把 nil 发送暴露给普通调用者：

func publish(ctx context.Context, optional chan

最后给三类状态分别写测试：正常 channel 能发送，nil channel 在取消后能返回，已关闭 channel 的行为被明确记录。不要用“测试没有超时”证明修复完成；应让测试本身带 deadline 或 context，确保错误不会把测试进程拖到永久等待。

常见问题

给 nil channel 重新赋值后，原来的发送会自动恢复吗？

会在发送仍处于等待状态且同一个变量确实被替换为可通信 channel 时恢复，但不要把这种隐式唤醒当作设计。更稳妥的方式是先初始化，再启动使用它的 goroutine。

nil channel 和关闭 channel 都不能发送吗？

结果不同：nil channel 的发送永久阻塞，关闭 channel 的发送立即 panic。日志没有 panic 但 goroutine 数量持续增加时，更应该先查 nil 或无人接收的等待路径。

select 里能不能用 nil channel 禁用一个 case？

可以，这是常见的动态门控技巧；但必须保证 select 还有能推进状态或响应取消的分支，否则所有 case 都不可用时仍会永久阻塞。