goroutine 无法被强制终止，只能协作退出；需通过 context.Context（如 WithCancel、WithTimeout）发送取消信号，goroutine 内用 select 监听并主动 return，否则忽略通知将导致 panic。
goroutine 无法被强制终止，只能协作退出
Go 没有类似 kill 或 stop() 的机制去强行干掉一个 goroutine。一旦启动，它就运行到自己结束——除非你主动设计退出路径。所有“取消”本质上是通知 + 响应：主逻辑发信号，goroutine 自己检查、清理、return。忽略这点，直接用 close(ch) 或往已关 channel 写数据，就会触发 panic: send on closed channel。
用 context.Context 是最通用、最安全的取消方式
官方推荐、跨包兼容、自带超时/截止时间支持，适合 HTTP handler、数据库查询、长轮询等真实场景。
-
context.WithCancel：手动调用cancel()触发退出（适合用户点击“停止”或首个结果返回后终止其余任务） -
context.WithTimeout或context.WithDeadline：自动取消，避免 goroutine 永远卡住（比如网络请求最多等 5 秒） - 必须在 goroutine 内用
select监听，不能只轮询 <code>ctx.Err()（否则会忙等、吃 CPU） - 别把
context.Background()直接传给长期运行的 goroutine——它永远不会被 cancel，等于放弃控制权
func worker(ctx context.Context) {
for {
select {
case <-ctx.Done():
fmt.Println("exiting:", ctx.Err())
return
default:
// 处理单个任务
time.Sleep(100 * time.Millisecond)
}
}
}用 chan struct{} 关闭平级 goroutine 更轻量
当多个 goroutine 地位对等、无父子关系、也不需要传递超时或请求范围值（如一组消费者监听同一队列），关闭一个空结构体 channel 是最简洁的选择。
- 必须用
struct{}类型：零内存开销，语义明确（只传信号，不传数据） - 用
close(stopCh)，而不是stopCh ：关闭后所有监听者立即收到信号；发送值需缓冲或阻塞，易漏收 - 别用
for range stopCh驱动循环：channel 关闭后range会退出，但你通常需要在退出前做清理（比如释放锁、关闭文件）
常见错误：channel 关闭 ≠ goroutine 终止
这是新手最容易混淆的一点。关闭 channel 只影响通信行为，对 goroutine 本身毫无约束力。下面这段代码看似“取消了”，实则两个 goroutine 仍继续跑：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
ch := make(chan int)
go func() { for i := 0; i < 10; i++ { ch <- i } close(ch) }()
go func() { for v := range ch { fmt.Println(v) } }() // ← 这里 range 会停，但若改成 for {} + select，就不会停真正要终止 goroutine，必须让它自己感知退出条件——要么监听 ctx.Done()，要么监听一个可关闭的 stopCh，并在 select 中响应。否则，哪怕 channel 关了，循环照常执行，资源照常占用。
复杂点在于：退出时机和清理顺序。比如 goroutine 正在写文件、持有着锁、或正在发 HTTP 请求，return 前得确保 defer 或显式清理被执行。这没有银弹，只能靠你在每个 case 分支里写清楚该做什么。
