不能随便 close(channel)，因为重复关闭会 panic，多 goroutine 竞争关闭易出错；关闭应由唯一写入方负责，推荐用 sync.Once 保障只关闭一次，或在明确终止条件后直接 close。
为什么不能随便 close(channel)？
Go 里 close() 一个已关闭的 channel 会 panic，错误信息是 panic: close of closed channel。更麻烦的是，多个 goroutine 同时试图关闭同一个 channel 时，谁先谁后不可控，极易触发这个 panic。
常见错误场景：worker 池中多个 goroutine 监听同一 done channel，都想“负责收尾”而各自调用 close()；或者 defer 里无条件 close()，但 channel 可能已被上游关闭。
- channel 关闭是单向、不可逆的操作，只能由“写入方”决定何时结束写入
- 读取方永远不该调用
close()，哪怕它认为任务已完成 - 多个写入方共用一个 channel 时，必须有且仅有一个明确的“关闭责任方”
用 sync.Once + channel 关闭的惯用模式
最轻量、无锁、线程安全的做法：把 close() 包在 sync.Once 里，确保只执行一次。适用于单写多读、或多个 goroutine 协作判断关闭时机的场景。
典型结构：
var once sync.Once
ch := make(chan int, 10)
<p>// 启动写入 goroutine（可能多个）
go func() {
defer once.Do(func() { close(ch) })
for i := range data {
select {
case ch </p><p>// 其他 goroutine 也可安全调用 once.Do(func() { close(ch) })，不会重复关闭
</p>
-
sync.Once开销极小，比加mutex更适合这种“一锤子买卖” - 不要把
once.Do()放在循环里，它本意就是“只做一次”，放错位置会导致 channel 永远不关 - 如果写入逻辑本身有明确的终止条件（如遍历完切片），直接在循环结束后
close()更清晰，无需once
select + done channel 配合关闭的边界处理
当 channel 是作为 worker 间通信的信号通道（比如 quit 或 stop），常配合 select 使用。此时关闭时机容易错判：比如在 select 外部 close，但某个 goroutine 正卡在 case 等待读取，就会漏掉最后一批数据。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
正确做法是让发送方主动控制关闭，并保证所有值都已发出：
// ✅ 安全：先发完所有值，再 close
for _, v := range items {
ch // ❌ 危险：用 select 发送，可能因接收方退出而丢数据
for _, v := range items {
select {
case ch
- 缓冲 channel 要配合理大小，否则
ch 可能阻塞，导致无法走到close() - 如果接收方可能提前退出，发送方应监听
donechannel 并及时中止，但关闭动作仍应由发送方统一执行 -
range ch会自动在 channel 关闭后退出，这是唯一推荐的“读完即停”方式，不要自己写for { select { case v, ok :=
context.Context 替代 channel 关闭的适用场景
当 channel 的作用是“通知停止”，而非“传递数据”，优先用 context.Context。它天然支持取消传播、超时、截止时间，且 ctx.Done() 返回的 channel 是只读、不可关闭的，彻底规避了 close 误操作问题。
例如 worker 循环：
func worker(ctx context.Context, ch
- 不要对
ctx.Done()返回的 channel 调用close()—— 它不是你创建的，也不该由你关 - 如果需要同时响应多个退出信号（如 signal + timeout + ch 关闭），用
select组合多个更清晰，而不是堆砌close()逻辑 - context 无法替代数据通道（
chan int），它只解决“控制流”，不解决“数据流”
channel 关闭真正的复杂点不在语法，而在责任归属——谁拥有关闭权、何时算“该关了”、有没有并发竞争。这些没法靠工具自动检测，得靠设计时就约定清楚。一个 channel 在代码里出现两次以上 close() 调用，基本可以认定是隐患。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
