最可靠的方式是用 context.Context 配合 select 监听 ctx.Done()，因其支持取消、超时、截止时间及父子传递；单独使用 chan struct{} 或 chan bool 易引发竞态、漏判、资源泄漏或饿死问题。
用 context.Context 配合 select 是最可靠的方式
Go 官方不推荐用 channel 专门“发停止信号”，因为单纯关闭一个 done channel 或发送布尔值容易引发竞态或漏判。真正健壮的做法是把 context.Context 传给 goroutine，在它内部用 select 监听 ctx.Done() —— 这既支持取消，也天然兼容超时、截止时间、父子传递等场景。
常见错误：自己定义 stopCh chan struct{} 然后 close(stopCh)，但接收端若没用 select + default 或没处理已关闭 channel 的重复读取，可能卡死或 panic。
-
context.WithCancel()最常用：父 goroutine 调用cancel()即触发所有监听它的子 goroutine 退出 - 别在 goroutine 内部调用
ctx.Cancel()（除非你明确要向下游传播取消） - 监听
ctx.Done()必须搭配select，不能直接读：<-ctx.Done()会阻塞，而select可与其他分支共存
为什么不用 chan bool 或 chan struct{} 单独控制
这类 channel 很容易写出“伪退出”逻辑：比如 goroutine 正在处理耗时任务（如 HTTP 请求、文件读写），收到信号后没做清理就 return，导致资源泄漏；或者多个 goroutine 共享同一个 stop channel，但只有一个能成功读到信号，其余被饿死。
更隐蔽的问题是关闭时机：如果 sender 在 goroutine 启动前就 close(stopCh)，接收端 <-stopCh 会立即返回，但此时 goroutine 可能根本没准备好；如果 sender 忘记 close，goroutine 就永远等下去。
立即学习“go语言免费学习笔记（深入）”；
-
chan bool需要显式发送true，易遗漏或重复发 -
chan struct{}关闭后可被无限读取，但无法区分“已关闭”和“尚未关闭”，必须配合额外状态变量 - 两者都不提供取消原因（
ctx.Err()可返回context.Canceled或context.DeadlineExceeded）
select 中监听 ctx.Done() 的典型写法
核心是：把业务逻辑和取消监听放在同一个 select 里，确保任意分支就绪都能及时响应。不要把取消逻辑单独抽成 if 判断。
go func(ctx context.Context) {
for {
select {
case <-ctx.Done():
log.Println("received cancel, cleaning up...")
// 执行清理：关闭文件、释放锁、通知下游等
return
case data := <-workCh:
process(data)
}
}
}(ctx)
- 循环内每次迭代都检查
ctx.Done()，避免一次 select 后继续跑下一轮 - 如果
process(data)可能阻塞且自身支持 context（如http.Client.Do(req.WithContext(ctx))），记得把 ctx 传进去 - 不要在
case <-ctx.Done():分支里再起 goroutine 做清理——它本身就在目标 goroutine 里，直接同步执行即可
goroutine 退出时的资源清理容易被忽略
很多人以为 “return 就完事了”，但 Go 不会自动关文件、释放 mutex、取消 pending 的 HTTP 请求。这些必须显式做，且要在 ctx.Done() 分支里完成。
- 打开的文件句柄、网络连接、数据库连接池里的 conn，都要在 return 前
.Close() - 持有
sync.Mutex或sync.RWMutex时，必须确保 unlock，否则其他 goroutine 永远阻塞 - 如果启动了子 goroutine（比如用
time.AfterFunc或另起协程轮询），也要一并停止或等待它们结束 - 用
defer不够——它只在函数 return 时触发，而 goroutine 可能长期运行，清理必须绑定到取消信号上
真正的难点不在“怎么发信号”，而在“收到信号后，哪些状态要还原、哪些资源要释放、哪些下游还要通知”。这部分没有银弹，得根据业务逻辑逐条梳理。
