go中context不能强制终止goroutine，仅通过关闭ctx.done()通道发送取消信号；goroutine必须主动用select监听该channel并在case分支中return或break，否则无法退出。
Go 里不能“杀掉” goroutine，context 取消只是发信号；真正退出必须靠你自己在 goroutine 里监听 ctx.Done() 并主动 return 或 break。
为什么 select { case 是唯一可靠写法
goroutine 不会因为 context 被取消就自动停止——它只会在你显式监听 ctx.Done() 时感知到关闭信号。漏掉 select、用 if ctx.Err() != nil 轮询、或单独写 （无 <code>select），都会导致阻塞或错过取消时机。
单独一行会永久阻塞，直到 context 关闭（可能永远等不到）-
if ctx.Err() != nil是错的：channel 没关时Err()还是nil，但你已该停了；channel 关了之后Err()才稳定可读 - 正确姿势是把
和业务 channel 放进同一个 <code>select，比如：select { case
cancel() 必须显式调用，且只调一次
context.WithCancel 返回的 cancel 函数不是开关，不调就不会发信号；调两次会 panic：panic: sync: negative WaitGroup counter（尤其和 sync.WaitGroup 混用时）。
- 别在
defer里过早注册：defer cancel()若函数提前 return，defer不执行 → 泄漏 - 别把
cancel传进 goroutine 后立刻调用 → 上游还没开始工作就结束了 - 安全做法：谁创建 context，谁负责调用
cancel()；若需跨层传递，用闭包或结构体字段封装，别用context.WithValue存cancel函数（不推荐）
HTTP handler 中的 context 自动取消，但新 goroutine 不会继承
req.Context() 由 HTTP server 自动管理：客户端断开、超时、主动关闭连接都会让 req.Context().Done() 关闭。但你在 handler 里启的新 goroutine 默认不会绑定这个 context —— 必须手动传入。
- ❌ 错误：
go sendNotification(r.Context(), msg)→ 客户端一走，通知就中断 - ✅ 正确：另起独立生命周期，比如
notifCtx, _ := context.WithTimeout(context.Background(), 5*time.Second)，再传给 goroutine - 数据库查询、HTTP client 请求等支持 context 的 API，务必传入该 context；它们内部会监听并提前中止底层操作
context 取消后，资源清理全靠你自己
调用 cancel() 只是关闭 ctx.Done()，不干涉正在执行的代码。如果 goroutine 正卡在 os.File.Read 或纯计算循环里，且没检查 ctx.Done()，它就根本收不到信号。
-
http.NewRequestWithContext、db.QueryContext这类 API 内部已集成监听，可直接用 - 对不支持 context 的 IO（如原生
os.File），需在每次读写前加select { case 判断 - 取消后是否关闭文件、释放锁、重置状态——这些全得你手写，context 不代劳
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
