只有最后一个可能往channel写数据的goroutine才有资格调用close()；否则会panic：close of closed channel或send on closed channel，接收方调用直接编译报错，多发送方竞态关闭或无人关闭均错误。
谁有资格调用 close()？
只有明确知道自己是「最后一个可能往 channel 写数据」的 goroutine，才能调用 close()。编译器不检查逻辑，但运行时会立刻 panic：panic: close of closed channel 或更危险的 panic: send on closed channel。
- 接收方调用
close()：编译期就报错 ——invalid operation: close(ch) (channel is receive-only) - 多个发送方各自判断“我写完了”就关：典型竞态，后执行的那个必 panic
- 主 goroutine 启动 N 个 worker 往同一
ch chan int写，却没设终结者：没人该关，也没人敢关 - 函数参数是
ch 或 <code>ch chan：前者不能关，后者能关但得确认你真是唯一写入者
for range ch 什么时候退出？
for v := range ch 只在两个条件**同时满足**时才退出：channel 已关闭 且 缓冲区中所有数据已被读完。漏掉任一，就会卡死或泄漏。
- 常见翻车：启动 goroutine 发送
ch ，紧接着 <code>close(ch)—— 若ch是无缓冲的，发送 goroutine 永远阻塞在，而 <code>range已退出，造成 goroutine 泄漏 - 有缓冲也不保险：若
cap(ch) == 10，你发了 8 个就close()，range能读完 8 个后退出；但若第 9 个还在发送途中，就可能 panic - 安全做法：用
sync.WaitGroup等所有发送 goroutine 显式 return 后，再close()；或改用select监听主动退出信号（如）
检测 channel 是否已关闭？别试了
Go 标准库没有线程安全、无副作用的函数能告诉你 channel 是否已关闭。网上流传的 select { case v := 技巧，本质是试探“此刻能否非阻塞接收”，它无法区分“channel 空了”和“channel 关了”。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
v, ok := 中 <code>ok == false只在 channel 关闭 且 缓冲为空时才成立；若缓冲还有数据，ok仍为true，你读到的可能是合法零值（比如发了个0）- 用
len(ch)或cap(ch)判断？完全无效 —— 它们只反映缓冲区状态，与关闭标志位无关 - 真正可靠的信号不是“channel 关了”，而是“我该停了”：用
context.Context控制生命周期，比依赖close()更正交、更可控
不关 channel，真的会泄漏或卡死吗？
绝大多数情况下，不调用 close() 不会导致泄漏。channel 本身无引用后会被 GC；只要接收方正确响应 ok == false 或 ，goroutine 就能自然退出。
- 强行关 channel，反而引入竞争和 panic 风险；而用 context 或哨兵值，逻辑更清晰、容错更强
- worker 间同步？用
chan struct{}配合select，根本不需关 - 流式数据结束信号？发一个
nil或自定义eof值，接收方识别后退出 - 生命周期受外部控制？用
ctx.Done()，sender 和 receiver 都监听，响应更快、更灵活
真正难的不是“怎么写 close(ch)”，而是判断“要不要关”——绝大多数时候，不关反而是更安全的选择。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
