go中goroutine无法被外部强制终止，优雅停机需协作式退出：通过context.context通知、select监听ctx.done()、使用带ctx参数的阻塞操作，并避免仅关闭channel就认为已退出。
Go 里没有“停机”这个词的直译操作——goroutine 无法被外部 kill，只能靠它自己感知信号、完成清理、然后 return。所谓“优雅停机”，本质是协作式退出：通知它该走了，并等它把活干完、把手头资源交还干净。
怎么用 context.Context 通知 goroutine 退出
这是最通用、最推荐的方式，尤其适合有父子关系或需要超时控制的场景（比如 HTTP handler、定时任务、DB 连接池）。
-
context.WithCancel或context.WithTimeout创建可取消上下文，传给 goroutine - goroutine 内必须用
select监听ctx.Done()，不能只轮询ctx.Err()（会忙等） - 所有可能阻塞的操作（如
http.Client.Do、net.Conn.Read、time.Sleep）都要优先选用带ctx参数的版本 - 别把
context.Background()直接传给长期运行的 goroutine——它永远不会结束，等于放弃控制权
为什么不能只 close(doneCh) 就认为 goroutine 停了
关闭 channel 只改变通信状态，对 goroutine 本身毫无约束力。常见错误是：close(stopCh) 后立刻往下走，以为它已退出；其实它可能还在 for 循环里、正在读文件、甚至卡在数据库查询上。
- goroutine 必须在
select的case 分支里执行清理并 <code>return - 如果坚持用 channel，
stopCh应为chan struct{}且带缓冲（make(chan struct{}, 1)），避免信号丢失 - 主 goroutine 关闭 channel 后，必须用
sync.WaitGroup或其他方式等待目标 goroutine 真正退出，否则可能泄漏 - 切忌在已关闭的 channel 上发送数据，否则 panic:
send on closed channel
goroutine 退出前必须做的三件事
光退出不清理，等于半途而废。很多线上 panic 和连接泄漏都出在这里。
- 释放资源：比如调用
db.Close()、redisPool.Close()、grpcServer.GracefulStop()—— 注意db.Close()是阻塞操作，要确保此前已无新查询发起 - 按反向依赖顺序关：先停消息消费者（如 Kafka），再等 DB 连接池归还连接，最后关 HTTP server；顺序错了轻则 panic，重则丢数据
- 清理本地状态：关闭文件、注销 etcd 租约、释放 mutex、清空缓存、写完最后一行日志……这些动作必须放在
case 分支里，而不是 defer 中
最容易被忽略的坑：没等真正结束就 exit
收到信号后调 cancel() 或 close(stopCh) 只是开始，不是结束。程序主 goroutine 必须显式等待所有子 goroutine 完成清理，否则 os.Exit(0) 会直接终止进程，导致 defer 不执行、连接不释放、日志截断。
- 用
sync.WaitGroup记录活跃 goroutine 数量，每个 goroutine 在清理完成后调wg.Done() - 主 goroutine 收到信号后，先触发 cancel / close，再
wg.Wait()，建议加超时保护（如 10 秒），避免卡死 - 不要在 signal handler 里做耗时操作；监听到信号后应异步启动停机流程，主 goroutine 继续阻塞等待 wg 完成
- Kubernetes 环境下，
terminationGracePeriodSeconds默认 30 秒，你的整体停机逻辑必须比它短，否则会被强制 kill
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
