重复关闭 channel 会 panic，因 Go 强制禁止 close 已关闭的 channel，错误为“close of closed channel”；常见于多 goroutine 竞态 defer 关闭、重复注册回调或局部 sync.Once 失效；sync.Once 是最稳妥封装方式，确保关闭逻辑只执行一次；多数场景其实无需 close。
重复关闭 channel 会直接 panic，不是 bug 是设计强制约束
go 运行时明确禁止对已关闭的 channel 再次调用 close()。一旦触发，程序立即崩溃，错误信息为 panic: close of closed channel。这不是偶发或环境问题，而是语言层硬性校验——它不静默忽略，也不返回错误，而是用 panic 暴露逻辑错误。
常见触发场景：多 goroutine 竞争关闭 + defer 无条件执行
实际代码中最容易踩坑的是以下组合：
- 多个函数（如
FibonacciGen()和调用它的Euler2()）各自在defer中写了close(ch) - 测试中启用
t.Parallel()或隐式并发，导致不同 goroutine 的defer队列竞态执行 - 封装的关闭逻辑被多次调用（比如重试回调、事件监听器重复注册后又触发）
- 结构体方法中新建了局部
sync.Once，每次调用都新建一个实例，失去“只执行一次”的意义
为什么 sync.Once 是最稳妥的封装方式
sync.Once 把“判断是否已执行”和“执行关闭”原子化打包，开发者只需关注“我要关”，不用操心“有没有人先关”。相比手动用 atomic.Bool，它避免两个关键风险：
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
atomic.Bool只能保护读写标志，无法防止两个 goroutine 同时通过CompareAndSwap判断为 false 后都去执行close() - 必须在每个发送分支都加判断，漏掉一处就等于裸奔；而
sync.Once.Do()是单点封装，调用一百次也安全 - 推荐绑定到结构体字段（如
once sync.Once），生命周期与ch一致；不要在函数内声明局部sync.Once
真正需要 close() 的场景其实很少
很多人默认“用了 channel 就得关”，但多数情况可以跳过 close()：
- 缓冲通道仅用于内部协程通信，靠
sync.WaitGroup控制生命周期 - 接收方用
for range ch，而发送方是有限循环且不会 panic，range会在发送结束自动退出 - channel 仅作信号通道（如
done chan struct{}）才值得关；纯数据通道若接收方不依赖v, ok := 判断关闭，关不关没区别
核心动机只有一个：让接收方能通过 ok 明确感知“发送已终结”。其余时候，不关反而更安全。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
