go中无法强制终止goroutine，唯一安全方式是通过context.context协作取消：调用cancel()关闭ctx.done()通道，goroutine主动监听并退出；withcancel用于手动取消，withtimeout用于时限控制，须用select监听ctx.done()避免泄漏。
Go 里不能“杀掉” goroutine，只能用 context.Context 让它自己停下来——这是唯一安全、可组合、与标准库对齐的方式。
为什么不能直接终止 goroutine？
Go 运行时不允许外部强制中断 goroutine，这是设计使然：避免资源泄漏、锁未释放、defer 不执行等不可控状态。所谓“取消”，本质是协作式通知：context 提供一个只读的 ctx.Done() channel，goroutine 主动监听并退出。
- 调用
cancel()只是关闭这个 channel，不干涉正在执行的代码 - 如果 goroutine 正卡在
os.File.Read或纯计算循环里，且没检查ctx.Done()，它就根本收不到信号 - 用
runtime.Goexit()可从任意深度退出当前 goroutine，但它不传播取消信号，也不能替代context的跨调用链能力
context.WithCancel vs context.WithTimeout 怎么选？
两者都返回可取消的 ctx 和 cancel 函数，区别只在触发时机：WithCancel 需手动调用 cancel()；WithTimeout 在指定时间后自动调用。
-
context.WithCancel(context.Background())：适合用户点击“停止”、API 被显式中止等需人工干预的场景 -
context.WithTimeout(parent, 3*time.Second)：适合 HTTP 请求、数据库查询等有明确响应时限的场景，更常用 -
context.WithDeadline(parent, time.Now().Add(3*time.Second))：语义上更精确（绝对时间），但和WithTimeout底层行为一致，一般优先选WithTimeout - 永远别在
select里混用time.After和ctx.Done()——time.After会泄漏 timer，正确做法是用context.WithTimeout
goroutine 内怎么正确监听取消？
唯一可靠方式是 select 等待 ctx.Done()，不能轮询 ctx.Err() != nil，也不能在 select 外单独检查。
- 错误写法：
if ctx.Err() != nil { return }—— 会错过取消瞬间，且可能永远不触发 - 正确写法：
select { case ，配合业务 channel 放在同一 <code>select中 - 阻塞 IO 必须用支持 context 的版本：比如
http.NewRequestWithContext、net.Conn.SetReadDeadline配合ctx.Deadline()，而不是对os.File盲套ctx - 忘记调用
cancel()会导致底层 timer 和 goroutine 泄漏，尤其在循环中反复创建WithCancel时要格外小心
Context 必须贯穿整个调用链
如果 worker 启动了子任务，子任务也必须接收并传递 ctx，否则取消信号传不下去。
- 不要在子函数里重新调用
context.Background()或context.TODO()—— 这等于切断取消链 - 下游函数签名应统一带
ctx context.Context参数，并在内部继续转发，例如doDBQuery(ctx, sql)→db.QueryRowContext(ctx, sql) - HTTP handler 中拿到的
req.Context()已自带取消能力，但若启长期 goroutine（如异步日志落库），必须派生新ctx，比如context.WithTimeout(req.Context(), 5*time.Second)，否则 handler 结束后 goroutine 还挂着
最常被忽略的一点：取消不是“立刻停”，而是“尽快停”。你得确保每个关键阻塞点（channel receive、IO read、sleep）都参与了 select + ctx.Done()，否则信号就卡住了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
