context 不能直接取消 goroutine，需主动检查 ctx.done() 并配合 return 或 break；其设计哲学是“通知而非中断”，通过 select 监听关闭的 chan struct{} 实现协作式退出。
Go 语言中，context 本身不能直接“取消 goroutine”，它只提供信号传递机制；真正退出 goroutine 需要你主动检查 ctx.Done() 并配合 return 或 break —— 这是绝大多数初学者卡住的第一步。
为什么 select + ctx.Done() 是标准写法
goroutine 无法被外部强制终止，context 的设计哲学是“通知而非中断”。ctx.Done() 返回一个只读的 chan struct{}，一旦 context 被取消，该 channel 就会关闭，从而在 select 中触发 case 分支。
常见错误是漏掉 select，或把 写成同步接收（导致阻塞）：
select {
case
- 永远不要写
单独一行（会永久阻塞） - 如果 goroutine 有循环逻辑，必须在每次迭代开头或关键等待点插入
select检查 -
ctx.Err()只应在退出后用于记录原因，比如log.Println("exit:", ctx.Err())
cancel 函数必须被显式调用，且只能调用一次
context.WithCancel 返回的 cancel 函数不是自动触发的，也不会被 GC 回收。不调用它，goroutine 就永远不会收到取消信号。
典型误用场景：
- 在 defer 中注册
cancel，但函数提前 return 了，defer 没执行 → 泄漏 - 多个地方重复调用同一个
cancel→ 第二次 panic：panic: sync: negative WaitGroup counter（如果还配了sync.WaitGroup） - 把
cancel传进 goroutine 里，但 goroutine 拿到后立刻调用 → 上游还没开始工作就结束了
安全做法是：谁创建 context，谁负责调用 cancel；若需跨层传递，用 context.WithValue 存 cancel 函数名（不推荐），更推荐用闭包或结构体字段封装。
HTTP handler 中的 context 自动取消，但业务 goroutine 不会自动继承
HTTP server 会在请求超时或客户端断开时自动取消 req.Context()，但如果你在 handler 里启了新 goroutine，它默认不会绑定这个 context —— 必须手动传入：
go func(ctx context.Context) {
for {
select {
case
- 别用
context.Background()替代r.Context()，否则超时/取消完全失效 - 数据库查询、HTTP client 请求等支持 context 的 API，务必传入该 context，它们内部会监听并提前中止底层操作
- 自定义 long-polling 或流式响应逻辑时，尤其要注意 goroutine 是否持有已过期的 context
最常被忽略的一点：context 取消只是发信号，goroutine 是否及时响应、是否清理资源（如关闭文件、释放锁、重置状态），全靠你自己写。没有自动回收，也没有魔法兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
