重复关闭 channel 会 panic，sync.once 是唯一安全的封装方式；需定义为结构体字段并用 p.once.do(close) 封装；测试中多个 defer close(ch) 是高频 panic 点，根本解法是明确关闭职责。
重复关闭 channel 会直接 panic，不是偶发错误，而是 go 运行时强制校验——一旦触发 panic: close of closed channel，程序立即崩溃。
为什么 sync.Once 是唯一安全的封装方式
手动加锁、用 atomic.Bool 或写 if !closed { close(ch); closed = true } 都不可靠。两个 goroutine 同时读到 false，都会进 close() 分支，照样 panic；状态变量和 close() 调用之间没有原子性，竞态窗口始终存在。
sync.Once 把“是否执行过”和“执行 close()”彻底绑定为一个不可分割的操作。调用一百次也只关一次。
- 必须把
once sync.Once定义为结构体字段（如type Producer struct { ch chan int; once sync.Once }），不能在函数内声明局部变量，否则每次调用都新建实例，失去意义 - 封装方法推荐这样写：
func (p *Producer) Close() { p.once.Do(func() { close(p.ch) }) }
测试中多个 defer close(ch) 是高频触发点
常见于 Euler 类题目测试：多个测试函数（Euler2、Euler4）并发运行，各自调用同一个生成器（如 FibonacciGen()），而两者都写了 defer close(ch)。
Go 测试默认并发执行，两个 defer 队列竞态执行，第二个 close() 必然 panic。
- 根本解法不是加锁或 recover，而是明确关闭职责：仅由生产者 goroutine 关闭，消费者绝不碰
close() - 如果生成器内部已启动 goroutine 并在结束时
defer close(ch)，调用方就不要再写任何close()或defer close(ch) - 临时排查可加
t.Parallel()注释或串行运行测试，但只是掩盖问题
哪些场景其实根本不需要显式 close()
多数 channel 不需要显式关闭，关了反而增加风险。真正需要 close() 的动机只有一个：让接收方能通过 v, ok := 或 <code>for range ch 明确感知“发送已终结”。其余情况不关更安全。
- 缓冲通道（
make(chan T, N)）只用于内部协程通信，生命周期由sync.WaitGroup控制 - 接收方用
for range ch，而发送方是有限循环且不会 panic，range会在发送结束自动退出 - 信号通道（如
done chan struct{}）用close(done)合理；但纯数据通道若接收方不依赖ok判断，关不关没区别
最易被忽略的是：close() 不是“善后动作”，而是通信协议的一部分。它意味着“我不会再发了”，一旦误用，就会同时引发 send on closed channel 和 close of closed channel 两类 panic —— 它们往往成对出现，根源却在同一个设计疏漏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
