panic 一定发生在向 channel 发送数据的代码行，但根源在于关闭 channel 的位置和时机错误；需反推关闭者、关闭时间及是否存在并发写入，常见如消费者提前 defer close(ch) 而生产者仍在循环写入。
panic: send on closed channel 怎么定位
这个 panic 一定发生在向 channel 发送数据的那行代码，但真正的问题不在那一行，而在关闭它的位置和时机。Go 运行时不会告诉你“谁先关的”，只报错“send on closed channel”。所以得反推：谁关了它？什么时候关的？还有 goroutine 在往里写吗？
常见路径有三类：
- 消费者（如测试函数
Euler2）提前退出并defer close(ch)，而生产者 goroutine 仍在循环ch - 多个函数（
FibonacciGen和调用它的Euler2）各自写了defer close(ch)，测试并发执行时竞态触发二次关闭，第二次 close 让 channel 进入关闭态，后续任何发送都 panic - 服务重注册逻辑中异步调用
close(taskChan)，但 task 分发 goroutine 还没退出，继续发送
查日志时重点盯 close(ch) 出现的位置，尤其注意是否在 defer 中、是否跨函数重复出现、是否被 t.Parallel() 放大。
sync.Once 封装 close() 为什么必须是结构体字段
因为 sync.Once 的作用域必须和 channel 生命周期一致。如果写成局部变量：
立即学习“go语言免费学习笔记（深入）”；
func CloseChan(ch chan int) {
once := sync.Once{} // ❌ 每次调用都新建，完全无效
once.Do(func() { close(ch) })
}
那每次调用 CloseChan 都是一个新 once，根本起不到“只关一次”的作用。正确做法是绑定到结构体：
type Producer struct {
ch chan int
once sync.Once
}
<p>func (p *Producer) Close() {
p.once.Do(func() { close(p.ch) })
}
这样 p.Close() 调一百次也只关一次，且能自然跟随 p 的生命周期。
用 nil channel 避免 send panic 的真实写法
不是靠“判断 channel 是否已关”——Go 没提供安全判断 API；而是让发送操作在 channel 关闭后**不可选**。核心是利用 select 对 nil channel 的 case 会永久忽略的特性。
关键细节：
-
writeCh必须是局部变量，初始为nil -
writeCh = ch必须放在default分支里，确保done就绪后它永远不被赋值 - 第二个
select中的writeCh 才真正受控：若 <code>writeCh == nil，该分支跳过，不 panic
完整骨架：
func writer(done <-chan struct{}, ch chan<-int) {
var writeCh chan<-int
for i := 0; ; i++ {
select {
case <-done:
close(ch)
return
default:
writeCh = ch // ✅ 仅当 done 未就绪才启用
}
select {
case writeCh <- i:
case <-done:
close(ch)
return
}
}
}
哪些地方根本不需要 close() 却常被误关
多数显式 close(ch) 是冗余甚至危险的。真正需要它的唯一动机是：让接收方能通过 v, ok := <-ch 或 for range ch 明确感知“发送终结”。其余场景关了反而多一层风险：
- 缓冲通道（
make(chan int, 10)）仅用于内部协程通信，靠sync.WaitGroup等待生产者退出即可，无需 close - 消费者用
for range ch读取，而生产者是有限循环（比如发 100 个数后 return），range 会自动退出，关不关没区别 - 信号通道（如
done chan struct{}）适合 close，但数据通道若接收方根本不检查ok，close 就只是制造 panic 风险的开关
最容易被忽略的一点：close() 不等于“所有写入已完成”。它只发信号，不等 goroutine 结束。若没用 sync.WaitGroup 或 context 显式等待生产者 goroutine 退出，就 close，那剩余的 ch 仍会 panic。
