Go 中 channel 关闭仅表示发送端无数据可发，接收端应停止等待；正确退出协程需用独立 done channel 广播信号，worker 通过 select 监听并主动退出。
Go 中 channel 的关闭机制不是用来“通知协程退出”的，而是用来**表示发送端已无数据可发、接收端应停止等待**。误用 close 会导致 panic 或逻辑混乱，真正优雅结束协程的关键在于：**用 channel 传递信号 + 接收方主动检查 + 发送方不盲目 close**。
什么时候该 close channel？
仅当明确知道：这是你（发送方）最后一次发送，且之后绝不会再向该 channel 发送任何值 —— 此时才能 close。常见于以下场景：
- 循环读取文件/数据库后，把所有结果发完，再 close done channel
- worker 池中，主 goroutine 把全部任务发完，close 任务 channel 表示“活干完了”
- 扇出（fan-out）结构中，一个 goroutine 负责聚合多个子 channel 结果，等全部子 goroutine 完成后 close 汇总 channel
⚠️ 错误做法：为“让接收方退出”而 close；或在多个 goroutine 中重复 close 同一个 channel（会 panic）。
如何安全地通知协程退出？用 done channel
标准做法是额外提供一个只读的 done channel（通常类型为 chan struct{}），由调用方关闭它来广播“该停了”。被管理的 goroutine 通过 select 监听 done，收到信号即退出：
立即学习“go语言免费学习笔记（深入）”；
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
func worker(id int, jobs <-chan int, done <-chan struct{}) {
for {
select {
case job, ok := <-jobs:
if !ok {
return // jobs 关闭，正常退出
}
fmt.Printf("worker %d: %d\n", id, job)
case <-done:
fmt.Printf("worker %d: received done, exiting\n", id)
return
}
}
}主 goroutine 在需要终止时 close(done)，所有监听它的 worker 都能立即响应。
如何避免“发送到已关闭 channel” panic？
如果发送方不确定接收方是否还在运行，就不要直接 send；更稳妥的方式是：
- 用
select+default实现非阻塞发送（失败就丢弃或记录） - 用带超时的
select避免永久阻塞 - 让发送方也监听 done channel，在收到退出信号时停止发送
例如：
select {
case results <- result:
// 成功发送
case <-done:
// 不再发送，直接退出
return
}常见组合模式：errgroup + context（推荐生产环境）
手动管理 done channel 容易遗漏。更健壮的做法是结合 context.Context 和 errgroup.Group：
ctx, cancel := context.WithCancel(context.Background())- 启动 goroutine 时传入
ctx，并在 select 中监听ctx.Done() - 调用
cancel()即可统一通知所有监听者 -
errgroup还能自动等待所有 goroutine 结束，并收集首个 error
这比裸写 done channel 更清晰、不易出错，尤其适合有依赖关系或需错误传播的场景。
