重复关闭 channel 会触发 panic: close of closed channel，sync.once 是唯一安全的封装方式，因它将判断与关闭原子化；局部 once 变量无效，必须作为结构体字段；消费者绝不应 close，多数场景根本无需显式关闭。
重复关闭 channel 会直接 panic，不是偶发错误，而是 Go 运行时强制校验——一旦触发 panic: close of closed channel，程序立即崩溃。这不是该不该加 recover 的问题，而是逻辑设计已暴露竞态或职责混乱。
为什么 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 }），不能在函数内声明局部变量，否则每次调用都新建实例，失去意义
测试中多函数 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自动退出 - 发送方是有限循环（如发 100 个数后 return），接收方不依赖
v, ok := 判断关闭，则关不关对行为无影响 - channel 作为信号通道（如
done chan struct{}）才需close(done)；纯数据通道，除非接收方要靠ok == false做清理，否则跳过close()更安全 - 真正需要
close()的动机只有一个：v, ok := 或 <code>for range ch依赖它来感知“发送终结”
nil channel 和已关闭 channel 的发送 panic 区别
这两个 panic 表面相似，但根源和修复方式完全不同：
-
panic: close of nil channel：说明你试图关闭一个未初始化的变量，如var ch chan int; close(ch)。修复就是确保ch = make(chan T)在close()前完成 -
panic: send on closed channel：说明有 goroutine 仍在向已关闭的 channel 发送，典型于生产者未退出就收到关闭信号。不能靠recover掩盖，必须用context+sync.WaitGroup协同退出，或用nil channel技巧让select自动跳过写入分支 - 注意：Go 没有 API 能安全判断 channel 是否已关闭，
v, ok := 是唯一合法检测方式，但它本身是一次接收操作，不能用来“预检”发送
最容易被忽略的一点：关闭 channel 不等于通信终止。缓冲区里残留的数据仍可被正常接收，零值和业务零值无法区分，所有接收端必须检查 ok；而 for range ch 会等缓冲耗尽才退出，不是 close() 后立刻停止。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
