<p>只有发送方能关闭通道且仅一次；拥有chan int或chan<- int类型者才有资格调用close(ch)，否则会panic。</p>
Go 里不能随便 close()，关早了、关多了、关错了类型，全都会 panic；安全关闭的核心就一条：**只由发送方关，且只关一次**。
谁有资格调用 close(ch)？
只有拥有 chan int 或 chan 类型变量的 goroutine 才能关 —— 接收方拿到的是 <code>，编译器直接报错：<code>invalid operation: close(ch) (cannot close receive-only channel)。
- 函数参数是
？别碰 <code>close()，你没权限 - channel 是别人传进来的双向通道（
chan T）？先确认文档或约定：谁负责发送，谁就负责关 - 多个 goroutine 同时往一个 channel 写？必须明确指定唯一“关闭责任方”，其他写入者退出前要通知它
怎么防止重复关闭？
运行时对重复 close(ch) 是硬 panic，recover() 拦不住。靠逻辑层防，不是靠异常处理。
- 用
sync.Once封装：把close(ch)包在once.Do()里，天然幂等 - 别在
defer里无条件关 —— 如果该 goroutine 可能被多次启动，或 channel 已由别处关过，就会炸 - 别在
select的default分支里关 —— 非阻塞分支极易误触发，尤其在高并发或超时场景下
接收方怎么判断 channel 关了？
没有 isClosed() 这种函数，也不能靠单值接收猜 —— 返回零值时，你根本分不清是收到了 0，还是 channel 已关且没数据了。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 必须用双值接收：
v, ok := ；<code>ok == false才代表已关且缓冲为空 -
for v := range ch底层就是做这个判断，简洁安全，但只适合“读完全部再停”的场景 - 如果需要“一检测到关闭就立刻退出”，就得手写
select+ok判断，不能依赖range
常见误操作与替代思路
有些场景硬要关 channel 反而增加复杂度，比如 sender 生命周期不可控、或跨包传递只读通道时。
- 用
context.Context替代关闭信号：传ctx.Done()给 receiver，比等 channel 关更灵活、可取消、可超时 - 发哨兵值（如
nil、struct{}{}或自定义EOF）代替关 channel，尤其适合插件或回调模型 - buffered channel 发送未完成就 panic？别指望关 channel 补救 —— 要么加
recover+ 显式通知，要么用sync.WaitGroup确保所有 sender 安然退出后再关
最易被忽略的一点：关 channel 不是“释放资源”的动作，而是“发信号”——它不销毁 channel，也不唤醒阻塞的发送者；它只告诉接收者：“不会再有新值了”。所以，关之前，务必确认所有该发的数据都已发出，且没有 goroutine 正在或即将向它发数据。
