Go 中 goroutine 不能被强制终止，只能通过信号通知其自行退出；强行中断会破坏内存安全、跳过 defer、丢失日志和半开连接；常见错误是 goroutine 卡在 runtime.gopark 或阻塞状态。
goroutine 不能被“杀”，只能被“通知退出”
Go 没有类似 thread.stop() 的强制终止机制——这是设计使然，不是缺陷。强行中断协程会破坏内存安全、跳过 defer、丢弃未 flush 的日志、留下半开连接。你真正能做的，是向它发送“该停了”的信号，由它自己决定何时干净收尾。
常见错误现象：pprof 显示大量 goroutine 卡在 runtime.gopark 或阻塞在 上；程序 <code>main 返回后仍有后台任务没执行完，数据写了一半就没了。
- 永远别用
os.Exit()或log.Fatal()在业务逻辑中“快速退出”——它们绕过所有清理 - 别在 goroutine 里调
cancel()（panic！），cancel只能由创建 context 的那一方调 - 不要靠
time.Sleep()硬等——你猜不准要等多久，超时丢数据，等太久拖慢发布
用 context.Context 实现可取消、带超时的退出控制
context 是 Go 官方推荐的标准方式，尤其适合需要协作取消、传递截止时间、或嵌套子任务的场景（比如 HTTP handler 启动了子 goroutine 去查数据库）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
context.WithTimeout(ctx, 5*time.Second)而非WithCancel——避免 goroutine 卡死导致主流程无限 hang 住 - 把
ctx作为第一个参数传给所有可能需响应退出的函数（如worker(ctx)、http.Server.Shutdown(ctx)） - 在 goroutine 内部用
select监听ctx.Done()，而不是轮询ctx.Err() != nil
示例关键片段：
ctx, cancel := context.WithTimeout(context.Background(), 8*time.Second) defer cancel() go worker(ctx) // ... 收到 SIGTERM 后 <-sigChan cancel() // 发出取消信号 wg.Wait() // 等 worker 自己退出
用 sync.WaitGroup + channel 配合信号监听做主流程守门人
WaitGroup 不负责“通知”，只负责“计数”：它让你的 main 函数不急着返回，而是老老实实等到所有已知的后台任务自然结束。但光靠它不够——你得先让 goroutine “知道该停了”，它才肯主动退出。
使用场景：HTTP server、长期运行的 worker pool、定时采集任务等明确生命周期的后台服务。
-
wg.Add(1)必须在go语句前调用，且不能漏；defer wg.Done()要包在 goroutine 最外层 - 别写
defer wg.Wait()在main里——defer在return后才执行，而main return就等于进程退出 - 监听
os.Interrupt和syscall.SIGTERM（Docker / systemd 用这个），别只监听 Ctrl+C
HTTP server 和 worker pool 的关闭陷阱
HTTP server 不能直接 srv.Close()，那会立刻断开所有连接；worker pool 如果只 close(jobs) 而不处理正在执行的 job，就会卡死或丢任务。
典型错误：
-
http.ListenAndServe()没包装成 goroutine，导致阻塞main，信号根本收不到 - worker pool 关闭时没等已接收 job 处理完，就提前
wg.Wait()，部分 job 被丢弃 - 没给
srv.Shutdown()设超时，客户端慢请求拖住整个关机流程
正确做法：
- HTTP server 用
srv.Shutdown(ctx)，并确保ctx有超时（比如 5–10 秒） - worker pool 先
close(jobs)，再wg.Wait()；每个 worker 内部必须检查ctx.Err()并尽早退出长期操作 - 数据库连接、文件句柄、第三方 client（如
redis.Client）都要显式.Close()，且最好也设超时
最常被忽略的一点：优雅退出不是“等所有事做完”，而是“给合理时间，超时则强制放弃”。真正的难点不在代码怎么写，而在判断哪些操作必须保、哪些可以舍、超时阈值设多少——这得看你的 SLA、下游容忍度和数据一致性要求。
