Go 关闭 channel 触发 panic 的所有权约束

Go 关闭 channel 触发 panic，通常不是 close 本身“随机失败”，而是关闭责任没有被明确收口。最稳妥的规则是：由发送方负责关闭，并且同一个 channel 只允许一个明确的关闭路径。接收方只负责读到关闭状态，不要为了“通知大家结束”去抢关闭权。

变化一句话：close 的约束是所有权约束

这里没有一个需要迁移的新版语法变化，真正需要调整的是对内置函数语义的理解：close(c) 表示“后续不会再有值发送到 c”，因此关闭者必须能证明发送已经结束。Go 文档明确说明，close 的参数必须是双向或发送方向 channel；关闭后，接收方仍能读完已经进入 channel 的值，空了以后再接收会得到元素类型的零值和 ok == false。

不要让接收方侧尝试关闭 channel，也不要在多个并发协程里无保护地调用 close()，只有明确持有写入所有权的一方才有资格关闭对应的 channel，这是从根源上避免关闭 channel 触发 panic 的最稳妥规则。

为什么三类场景会直接 panic

排障时先不要把所有 panic 归成“并发不安全”。三类触发条件对应三种不同的责任错误：

func demonstratePanicCases() {
	var nilCh chan int
	// nil channel 不能被关闭；这个分支会 panic，生产代码不要用 recover 掩盖它。
	close(nilCh)

	ch := make(chan int)
	close(ch)
	// 同一个 channel 只能关闭一次；第二次 close 会 panic。
	close(ch)
}

上面的代码只用于标出边界，不能作为业务测试的连续执行样例，因为第一次 panic 会中断函数。实际排查应把每个边界放进独立测试用例，并让测试名称说明责任错误。

对旧代码的影响：接收方不要代替发送方关闭

很多旧代码把“消费者已经拿够数据”误写成“消费者可以关闭数据 channel”。但生产者可能还在发送，消费者一旦 close，下一次发送就会 panic。接收端应通过取消信号告诉生产者停止，或者由拥有全局生命周期的协调者等待生产者退出后再关闭数据 channel。

func produce(out chan

这个模式的关键不是把 close 机械地放进 defer，而是确认 defer 所在的函数确实拥有发送生命周期。如果有多个生产者，就不能让每个生产者都执行 close(out)。

迁移建议：多生产者用协调者统一收口

多生产者场景中，关闭动作应发生在“最后一个生产者退出”之后。可以让每个生产者只发送和退出，由协调 goroutine 等待全部生产者完成，再执行唯一一次关闭。这样发送者不会和关闭者争抢时序，接收端也能得到稳定的结束信号。

func fanIn(values ...[]int) 

如果生产者还可能因为取消而提前返回，取消逻辑必须同时保证它不再发送；否则仅仅关闭一个额外的停止 channel，并不能让已经在发送路径上的 goroutine 自动变得安全。

最小验证：把所有权、退出和接收结果逐项对上

迁移完成后，用下面的清单做最小验证。它不是线上验证，而是代码审查和单元测试应覆盖的责任关系：

最终判断标准很简单：发送方决定何时不再发送，协调者在所有发送方退出后关闭，接收方只消费并判断 ok。只要这三种角色没有混在同一条不透明的退出路径里，关闭 channel 的 panic 通常就能从“偶发并发问题”变成明确的责任分配问题。

常见问题

接收方什么时候可以关闭 channel？

只有当接收方同时拥有“之后绝不会再有发送者”的可靠证明时才可以。一般业务中更安全的做法是由发送方或协调者关闭。

关闭 channel 后还能读取数据吗？

可以。已经发送或缓冲的值仍可读完；读完后得到元素零值和 ok == false。因此不要只根据零值判断结束。

用 sync.Once 包住 close 就不会有问题吗？

sync.Once 可以避免多个调用者重复执行 close，但不能修复关闭过早导致的发送 panic，也不能替代“所有发送者已经退出”的生命周期设计。