Go中无法强制终止goroutine，必须由其主动退出；优雅关闭的核心是通过context.Context（推荐）或channel通知goroutine感知信号、清理后return。
Go 中无法强制终止 goroutine，必须靠它自己退出——所有“优雅关闭”的本质，就是让 goroutine 主动感知退出信号、完成清理、然后 return。
用 context.Context 通知退出最通用
这是官方推荐、跨包协作最稳妥的方式，尤其适合有父子关系或超时/取消需求的场景，比如 HTTP handler、数据库连接池、定时任务等。
-
context.WithCancel用于手动触发退出；context.WithTimeout或context.WithDeadline自动带超时逻辑 - goroutine 内必须用
select监听ctx.Done()，不能只轮询ctx.Err()（会忙等） - 别把
context.Background()直接传给长期运行的 goroutine——它永远不 cancel，等于放弃控制权
用 channel 传递关闭信号最直观
适合平级 goroutine 之间简单通信，代码清晰、无依赖、易理解。
- 推荐用
chan struct{}（零内存开销），而不是chan bool或带缓冲的 channel - 主 goroutine 关闭 channel（
close(stopCh)），worker 通过select { case 响应 - 切勿在已关闭的 channel 上发送数据，否则 panic：
send on closed channel - 如果 worker 还要向其他 channel 发送结果，需在
case 分支里提前return，避免后续写入
信号捕获 + WaitGroup 等待是完整退出链
单个 goroutine 退出不等于程序可安全退出。真正“优雅关闭”需要三步协同：捕获信号 → 通知退出 → 等待清理完成。
立即学习“go语言免费学习笔记（深入）”；
- 用
os/signal.Notify监听SIGINT和SIGTERM，channel 必须带缓冲（如make(chan os.Signal, 1)），否则可能漏信号 - 用
sync.WaitGroup记录所有活跃 worker，每个 worker 在defer wg.Done()前完成资源释放（如关闭文件、断开连接） - 主 goroutine 收到信号后，先调用
cancel()或close(stopCh)，再wg.Wait()；建议加超时保护，避免卡死
常见错误：误把 close(ch) 当作 goroutine 终止指令
关闭 channel 只影响通信状态，对 goroutine 本身毫无控制力——它仍会继续执行循环体里的逻辑，甚至尝试向已关 channel 写入而 panic。
- 错误模式：
close(done); time.Sleep(10 * time.Millisecond)就认为 goroutine 已停 - 正确做法：goroutine 必须在
select中监听ctx.Done()或，并在分支中return - 竞态场景下（如多个 goroutine 同时查错），由首个完成者调用
cancel()，其余自动退出，无需共享 channel
最容易被忽略的一点：goroutine 退出前的清理动作（比如 db.Close()、http.Server.Shutdown()）必须放在 case 分支里，而不是 defer 中——因为 defer 在函数返回时才执行，而你得确保清理发生在收到信号之后、且不被后续逻辑干扰。
