<p>向已关闭的 channel 发送数据会直接 panic，这是最常踩的坑：只要执行 ch <- x 就会触发 panic。</p>
向已关闭的 channel 发送数据会直接 panic
这是最常踩的坑：只要执行 ch 向一个已调用过 <code>close(ch) 的 channel 发送，程序立刻崩溃，报错 panic: send on closed channel。这不是可选警告，是运行时强制终止。
- 即使 channel 带缓冲、且缓冲区还有空位，关闭后仍不可写
- 多个 goroutine 并发写入时，若某一个先 close，其余 goroutine 一旦尝试发送，必 panic
-
recover()能捕获，但属于掩盖设计缺陷，不推荐用于兜底
从已关闭的 channel 读取是安全的，但行为分阶段
关闭不等于清空。读取行为取决于当前状态：
- 缓冲区还有未读数据 → 正常返回值，
ok == true - 缓冲区已空，但 channel 刚关闭 → 立即返回零值（如
0、""、nil），ok == false - 用
for v := range ch→ 自动在第二阶段退出，无需手动判断
注意：无法区分“收到的是发送方真发的零值”和“channel 关闭后的零值”，所以别依赖零值做业务逻辑判断；必须用 v, ok := 或 <code>range 显式感知关闭。
谁该关、什么时候关、怎么防重复关
关闭权只属于发送方，且仅当它**确定自己不会再发任何值**时才可调用 close()。接收方关 = 潜在 panic；多个发送方争着关 = 必 panic。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 单发送方场景：发完全部数据后，由该 goroutine 调用
close(ch) - 多发送方场景：不能靠“谁最后发完谁关”，而应统一协调——用
sync.Once封装关闭逻辑：var once sync.Once safeClose := func(ch chan int) { once.Do(func() { close(ch) }) } - 绝不要在
select的default分支里关 channel —— 非阻塞分支极易误触发
关闭不是退出通知，done channel 才是协程终止信号
很多人误以为 close channel 是用来“让 worker 停下来”的，其实不是。close(ch) 只表示“数据流结束了”，不表示“你可以退出了”。worker 是否该停，取决于它是否还被需要；而这个决策，得靠独立的 done chan struct{}。
- 主 goroutine 在想停时
close(done)，所有监听它的 worker 通过select立即响应 - worker 自己负责清理、退出，而不是等
jobschannel 关闭才走 - 生产环境更推荐
context.Context+errgroup.Group，自动处理取消、超时、错误传播
最容易被忽略的一点：关闭 channel 不会杀掉任何 goroutine，也不会释放内存，它只是一个信号。真正决定程序能否干净退出的，是你有没有让每个接收者完成自己的循环，以及有没有确保没有 goroutine 还在往那个 channel 发送。
