Go 关闭已经关闭的 channel 为什么会 panic

写Go并发逻辑的时候，不少人都踩过这个坑：不小心把同一个channel重复close了一次，程序直接就抛出panic崩溃了，很多人一开始都纳闷为什么Go要做这么严格的限制，而不是默默忽略掉第二次关闭的操作。

重复关闭已经关闭的channel会触发panic，是Go runtime 内置的强制安全规则，用来避免多协程环境下多个调用方无感知地操作同一个已关闭管道，引发更难溯源的业务异常。

如果 Go 程序报出 panic: close of closed channel，原因不是 channel 需要“多关几次”来释放资源，而是同一个 channel 的关闭动作已经发生过。Go 规范明确规定：关闭已关闭的 channel 会触发运行时 panic；向已关闭 channel 发送同样会 panic，但从已关闭 channel 接收是合法的，数据读完后会得到元素类型的零值。

先区分三种 channel 操作结果

排查时先看 panic 所在的操作，不要把所有“关闭后的行为”混成一类。对一个已经关闭的 chan int，结果可以概括为：

另外，关闭 nil channel 也会 panic；对 nil channel 接收或发送则会一直阻塞。这个差异很适合在代码审查时作为第一张检查表。图 1 用状态转移表达了“关闭是一次性状态变化”，它是本文的原创示意图，不是运行截图。

把 close 责任交给唯一的发送方

最稳的约定是“谁生产最后一个值，谁负责关闭”，更准确地说，是由能够确认所有发送已经结束的发送侧协调者关闭。接收方不应该为了让 range 退出而主动关闭输入 channel，因为它无法知道是否还有发送者。

func produce(out chan

这个结构有两个边界：produce 只能接收发送方向的 channel，consume 只能接收接收方向的 channel；类型本身就减少了误用机会。如果发送方提前返回，defer close(out) 仍然会执行，但前提是这个函数确实是唯一发送者。

多生产者要等所有发送结束后再关

常见的错误写法是让每个 worker 都在退出前 close(out)。第一个 worker 退出时看起来没问题，第二个 worker 退出就会触发 close of closed channel；更糟的是，其他 worker 可能还在发送，导致 send on closed channel。

把关闭动作提升到一个独立协调者，等待所有生产者完成：

func produce(out chan

这里的关键不是 WaitGroup 本身，而是关闭权只有一个。wg.Wait() 保证两个 worker 都已经执行完最后一次发送，随后协调者再关闭输出 channel。若生产者数量来自切片，应在启动 goroutine 前一次性完成 Add，不要让并发中的 Add 与 Wait 形成新的生命周期竞态。

取消场景用 done channel 广播退出

业务取消和数据结束是两件事。数据 channel 的关闭表示“不会再有新值”，而 done channel 的关闭表示“相关 goroutine 应该停止当前工作”。把两者分开，能避免消费者退出后，生产者仍卡在发送上，也能避免每个 goroutine 都去关闭业务 channel。

func worker(done 

如果取消时仍有多个发送者，协调者要先让 worker 从发送循环返回，再关闭数据 channel。官方 Pipeline 模式也采用“阶段关闭自己的输出、上游持续接收或响应取消”的思路。不要用“先 close，再 recover”来掩盖生命周期设计问题。

用 panic 定位问题，不把 recover 当并发方案

recover 可以把 panic 转成日志或测试结果，但不能让一个已经错误关闭的 channel 重新变成可发送状态。它适合包边界、任务隔离或测试断言，不适合作为每次关闭前的常规保护。

func observeClose(ch chan int) (panicked bool) {
	defer func() {
		if recovered := recover(); recovered != nil {
			// 只记录真实错误，生产代码仍应修正关闭责任。
			log.Printf("unexpected channel close: %v", recovered)
			panicked = true
		}
	}()
	close(ch)
	return false
}

在真实项目里，先沿着 close 的调用链找所有写入点，再标记 channel 的创建者、发送者和关闭者。若关闭者不止一个，优先重构所有权；只有在确实需要多个入口触发同一动作时，才考虑把“一次性动作”封装到拥有状态的对象中，并让对象统一负责关闭。

上线前的 channel 关闭检查清单

• 是否只有一个明确的关闭者？这个角色能否确认所有发送者已退出？
• 接收方是否错误地关闭了自己不拥有的输入 channel？
• 所有发送循环是否能响应 done 或 context.Context 的取消？
• 是否把 nil channel、重复 close 和 send-after-close 的测试分开写？
• 是否使用 -race 辅助发现共享状态问题，但没有把它当作 channel 所有权规则的替代品？

常见问题

为什么从已关闭 channel 接收不会 panic？

关闭是发送方告诉接收方“不会再有新值”的结束信号。接收方可以读完缓冲区，之后通过 ok == false 结束。

能不能在 close 前用 select 判断 channel 是否已关闭？

不能用一个通用的无竞态判断来代替所有权协调。即使刚刚观察到 channel 仍可用，其他 goroutine 也可能在下一刻关闭它。

多个 goroutine 都可能触发关闭，应该加 mutex 吗？

互斥锁只能保护“谁先执行 close”，不能自动证明其他发送者已经停止。应先收敛关闭责任，必要时再用锁或一次性状态保护外围业务状态。

关闭 channel 后还需要把它设为 nil 吗？

通常不需要。把变量设为 nil 只会改变该变量后续的阻塞行为，不能修复其他 goroutine 持有的 channel 引用，也不能撤销已关闭状态。