Go语言中无法强制终止goroutine，只能通过context.Context或done channel协作退出；close(done)仅关闭通道，不终止goroutine，若未在select中监听并return，协程仍会继续执行导致资源泄漏。
Go 语言中无法安全地“停止”其他 goroutine，只能让目标 goroutine 自己退出。这是语言设计的硬性限制，不是技巧问题——任何试图从外部 kill、中断或强制终止的行为（比如用 runtime.Goexit() 在别的 goroutine 里调）都无效甚至 panic。
为什么不能用 close(done) 当退出信号
很多人写 close(done) 然后在 goroutine 里 select { case ，以为这样就能退出。但关闭 channel 后，<code> 会**立即返回 <code>struct{}{} 零值**，而不是阻塞等待。如果 goroutine 正卡在 net.Conn.Read 或 time.Sleep 这类阻塞调用上，它根本没机会执行到那个 select，信号就丢了。
- 关闭 channel 不是“发消息”，而是“声明不再发”，对正在阻塞的接收方无唤醒能力
- 若 goroutine 启动后还没进入监听循环，
close(done)就已执行，那它永远收不到 - 多次
close(done)会 panic，必须确保只关一次
用 context.Context 是最可靠的选择
context.Context 的 Done() 返回一个只读 channel，且天然支持传播、超时、取消嵌套，比手写 channel 更健壮。关键不是“传进去”，而是 goroutine 内部必须在每个可能阻塞的地方监听它。
- 所有阻塞点都要进
select：比如http.Client.Do(req.WithContext(ctx))替代裸http.Get - 避免
default分支轮询：if ctx.Err() != nil会 CPU 忙等，必须用case - 父子 context 要正确传递：不要把
context.Background()直接塞给长期 goroutine，否则永远关不掉 - 启动 goroutine 的代码要配合
sync.WaitGroup或接收完成通知，否则无法确认它真退出了
runtime.Goexit() 只能在当前 goroutine 内部调用
runtime.Goexit() 是唯一能从任意函数调用深度（比如嵌套 5 层的 parse → validate → load → check → Goexit()）立即终止当前 goroutine 并执行所有 defer 的标准方式。但它不是“停止别人”，而是“自己立刻退场”。
立即学习“go语言免费学习笔记（深入）”；
- 跨 goroutine 调用无效，且会 panic
- 不能在
defer函数里调用，会导致 defer 链断裂甚至死锁 - 它不触发 panic，所以外层
recover()捕获不到 - 适合做“紧急自毁”：比如配置加载失败、证书校验不过，当前 goroutine 已无继续意义
真正难的不是选哪个机制，而是确保 goroutine 内部每一个可能卡住的位置——无论是 Read、Write、time.Sleep 还是第三方库的阻塞调用——都接入了退出信号。漏掉一个，就等于留了个永远跑下去的 goroutine。
