重复关闭 channel 必然 panic，错误固定为“panic: close of closed channel”；sync.once 是唯一可靠方案，因它将判断与关闭原子绑定，但需定义为结构体字段而非局部变量。
重复关闭 chan 会立刻 panic，不是偶发问题，而是 Go 运行时强制终止——错误信息固定为 panic: close of closed channel。只要代码路径里存在两次对同一 channel 调用 close()，就一定会崩，不存在“看运气”。
为什么 sync.Once 是唯一靠谱的封装方式
手动加 atomic.Bool 或 if !closed { close(ch); closed = true } 看似能防重关，但实际藏两个硬伤：
- 两个 goroutine 同时读到
false，都进close()分支，还是 panic -
closed变量和close(ch)之间没原子性，竞态窗口始终存在
sync.Once 把“判断是否执行过”和“执行 close()”彻底绑成一个不可分割的操作。调用一百次也只关一次。
关键点：必须把 once sync.Once 定义为结构体字段（如 type Producer struct { ch chan int; once sync.Once }），不能在函数内声明局部变量——否则每次调用都新建实例，完全失效。
测试中 defer 关闭导致 panic 的真实路径
常见于 Euler 类题目测试：多个测试函数（Euler2、Euler4）并发运行，各自调用同一个生成器（如 FibonacciGen()），而两者都写了 defer close(ch)：
-
FibonacciGen()内部启动 goroutine 发送数据，并在结束时defer close(ch) -
Euler2()消费部分数据后提前退出，也在函数末尾defer close(ch) - Go 测试默认并发执行，两个
defer队列竞态执行，第二个close()必然 panic
根本解法不是加锁，而是明确关闭职责：仅由生产者 goroutine 关闭，消费者绝不碰 close()。
哪些场景其实根本不需要显式 close()
多数 channel 不需要显式关闭，关了反而增加风险：
- 缓冲通道（
make(chan T, N)）只用于内部协程通信，生命周期由sync.WaitGroup控制 - 接收方用
for range ch读取，发送方是有限循环且不会 panic，range会在发送结束自动退出 - channel 作为信号通道（如
done chan struct{}），用close(done)合理；但若只是传递数据，且接收方不依赖v, ok := 判断关闭，关不关没区别
真正需要 close() 的动机只有一个：让接收方通过 v, ok := 或 <code>for range ch 明确感知“发送已终结”。其余时候，不关更安全。
最容易被忽略的是：关闭 channel 并不等于写入 goroutine 已退出。如果还有 goroutine 在往里发数据，哪怕你已经 close()，下一次 ch 就 panic。必须用 <code>sync.WaitGroup 或 context 显式等所有发送者真正停住，再关。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
