Go channel 关闭责任的所有权设计

Go channel 最稳妥的关闭规则可以压缩成一句话：谁知道“以后不会再发送”，谁负责关闭；如果有多个发送者，就把关闭动作交给等待所有发送者结束的汇聚者。 接收方只负责接收，通常用 for range 等到 channel 关闭后自然退出。

这条规则解决的不是语法问题，而是所有权问题。关闭前没有统一责任人时，最常见的结果是重复 close 触发 panic，或者接收方一直等待导致 goroutine 泄漏。下面用一个生产者、一个消费者和一个多生产者汇聚场景，把边界固定下来。

官方参考：https://go.dev/ref/spec#Close

并发流水线参考：https://go.dev/blog/pipelines

先把“最后一次发送”交给一个明确的 owner

一个 channel 只有一个生产者时，生产者天然知道自己的输入什么时候耗尽。它应当创建输出 channel、负责所有发送，并在 goroutine 退出前关闭输出。函数签名可以把返回值暴露为接收方向，让调用者从类型上看出自己没有关闭权限。

package main

import "context"

// produce 只有一个发送者，因此它拥有 out 的关闭责任。
func produce(ctx context.Context, values []string) 

这里的关键不是 defer 本身，而是关闭动作和发送动作被放在同一个所有者中。接收方拿到的是 ，它可以读取，但不能调用 close；生产者的所有返回路径又都经过同一个 defer close(out)。

让接收方用 range 等待关闭，而不是猜数量

接收方如果提前知道固定数量，可以按数量接收；但流水线、文件读取和任务分发通常更适合使用 range。当 channel 被关闭后，已经进入缓冲区的值仍会被读完，随后 range 退出。这样接收方不需要知道生产者内部有多少条数据。

func consume(ctx context.Context, values []string) {
	stream := produce(ctx, values)

	// range 会持续接收，直到 produce 关闭 stream。
	for value := range stream {
		// 这里处理一个已经确认来自生产者的值。
		println(value)
	}

	// 能走到这里，说明 stream 已关闭且缓冲值已经消费完。
}

不要把“当前没有值”当成“生产结束”。未关闭的 channel 可能只是暂时没有数据，直接退出会丢失后续发送；而一直等待一个永远不会关闭的 channel，则会留下阻塞的接收 goroutine。结束条件应该由真正的生产 owner 发出。

多个发送者时，关闭权交给汇聚者

多个 worker 共同写入一个输出 channel 时，任何一个 worker 都不知道自己是不是最后一个发送者，因此 worker 不能自行关闭公共输出。正确做法是让 worker 只发送，让一个单独的协调 goroutine 等待所有 worker 退出，再执行唯一一次 close(out)。

package pipeline

import "sync"

// merge 把多个只读输入汇聚成一个只读输出。
func merge(inputs ...

这里有三个不同角色：输入生产者关闭各自的输入 channel；转发 worker 读取输入并发送到 out；等待 WaitGroup 的协调者关闭公共输出。把这三种责任写在不同层级，能避免“某个 worker 先退出就顺手 close”造成的竞态。

重复 close 和发送到已关闭 channel 为什么会 panic

close(ch) 表示“不会再有值发送到 ch”。它不是广播式的“请大家停止”，也不是可以重复调用的幂等操作。对已经关闭的 channel 再次关闭会触发 close of closed channel；关闭后仍发送则会触发 send on closed channel。

因此，不建议用 recover 包住 close 来伪装成安全关闭。这样只能把所有权设计错误隐藏起来，无法解决另一个 goroutine 仍在发送的问题。更可靠的排查问题是：

• 谁创建了这个 channel，谁能判断最后一次发送已经完成？
• 关闭者是否只有一个，还是每个 worker 都可能执行 close？
• 公共输出关闭前，是否已经等待所有发送者退出？
• 接收方放弃时，发送方是否有取消分支可以返回？

把数据关闭和取消信号分成两条边界

业务数据 channel 的关闭表示“不会再有数据”；取消信号表示“请停止当前工作”。两者可以同时出现在一个系统里，但不应该混成“谁都能关”的公共开关。上面的 ctx.Done() 由 context 的取消所有者控制，out 仍由发送者或汇聚者关闭。

当接收方只消费第一条结果就返回时，生产者若没有取消分支，可能永远卡在发送操作上。此时应由调用方取消 context，生产者在 select 中退出，随后仍由生产者自己的 defer close(out) 完成数据边界的收尾。不要让接收方为了“帮忙清理”去关闭一个仍由生产者写入的 channel。

发布前用四个问题检查关闭责任

把 channel 当成带所有权的资源，代码就会清晰很多：发送方负责声明数据终点，接收方负责消费，多个发送者由汇聚者统一收口；取消路径另行表达。只要一个 channel 的关闭者能在代码审查中被一句话指出，重复关闭和 range 不退出通常就不会再靠运气处理。

几个容易混淆的问题

接收方可以关闭 channel 吗？

语法上某些接收方向以外的 channel 变量可能允许调用关闭，但设计上不应由不知道发送状态的接收方关闭。接收方提前关闭会让仍在发送的 goroutine 触发 panic。

关闭 channel 后还会丢掉缓冲值吗？

不会。关闭只禁止新的发送；已发送到缓冲区的值仍然可以被接收，读完后接收操作才会得到元素类型的零值和关闭状态。

多个发送者能不能用一个布尔变量标记最后一个？

不要用未经同步的标记猜测最后一个发送者。用 sync.WaitGroup 等待全部发送者结束，再由一个协调者关闭输出，责任边界更直接。