不能直接传 context.Context 后不管，因为 Context 仅为只读信号源，子协程须主动监听 ctx.Done() 并清理；否则即使父 Context 取消，子协程仍可能泄漏或返回脏数据，如 select 漏写 case。
为什么不能直接把 context.Context 传给子协程后就不管了
很多人以为只要在启动 go 协程前把 context.Context 传进去，子协程就能自动响应取消——其实不会。context.Context 本身不带执行逻辑，它只是个只读信号源；子协程必须主动监听 ctx.Done() 并做清理，否则即使父 Context 被 cancel，子协程仍可能跑满、泄漏或返回脏数据。
常见错误现象：select 漏写 case 、用 <code>ctx.Value 但没传入派生的子 Context（比如忘了用 context.WithCancel 或 context.WithTimeout）、在子协程里直接用了原始 context.Background()。
- 所有子协程都该用
ctx的派生版本（如context.WithCancel(ctx)），而不是复用同一个ctx实例 - 如果子协程要发 HTTP 请求或调用数据库，必须把
ctx显式传给http.NewRequestWithContext或db.QueryContext等函数 - 不要在子协程里用
context.WithTimeout(context.Background(), ...)—— 这会完全脱离父级生命周期控制
怎么安全地在多协程间汇总结果并响应 Context 取消
核心是：每个子协程独立监听 ctx.Done()，结果通过带缓冲的 channel 收集，主 goroutine 用 select 控制超时或提前退出，并确保所有子协程能被及时通知停止。
典型场景：并发调用多个微服务接口，任一失败或超时就中止其余请求，同时不遗漏已成功的结果。
立即学习“go语言免费学习笔记（深入）”；
示例关键片段：
results := make(chan Result, len(urls))
var wg sync.WaitGroup
<p>for _, url := range urls {
wg.Add(1)
go func(u string) {
defer wg.Done()
// 每个子协程都用自己的子 Context（带独立取消）
childCtx, cancel := context.WithTimeout(ctx, 5*time.Second)
defer cancel()</p><pre class="brush:php;toolbar:false;"> select {
case <-childCtx.Done():
results <- Result{URL: u, Err: childCtx.Err()}
return
default:
// 实际工作，比如 http.Get
resp, err := http.DefaultClient.Get(childCtx, u)
if err != nil {
results <- Result{URL: u, Err: err}
return
}
defer resp.Body.Close()
results <- Result{URL: u, Data: readBody(resp)}
}
}(url)}
// 主协程等待完成或 Context 取消 go func() { wg.Wait() close(results) }()
for i := 0; i
context.WithCancel 和 context.WithTimeout 在协程汇总中的选择差异
两者都能传递取消信号，但语义和使用时机不同：前者适合“由外部主动触发终止”（比如用户点了取消按钮），后者适合“固定时间窗口内必须结束”。混用时容易出问题。
- 如果主流程有明确 deadline（如 API 接口总耗时 ≤ 3s），优先用
context.WithTimeout(parentCtx, 3*time.Second)，子协程再各自用WithTimeout设置更短的单次上限 - 如果需要手动控制终止（比如后台任务被管理端下发 stop 命令），用
context.WithCancel，并在收到命令时调用cancel()；注意：cancel函数必须跨协程安全调用，且只能调一次 - 避免对同一
ctx多次调用WithCancel—— 派生出的子 Context 互不影响，但多次 cancel 同一个父 Context 是允许的（后续调用无副作用）
容易被忽略的 Context 传递细节：Value、Deadline、Done 的一致性
子协程拿到的 ctx 必须和父协程保持“信号同步”：如果父协程的 ctx.Deadline() 改变了，子协程用的派生 ctx 也得反映这个变化，否则会误判超时。
常见坑点：
-
ctx.Value不会自动跨协程传播 —— 如果你在主协程存了ctx = context.WithValue(ctx, key, val)，子协程必须显式接收并使用这个ctx，不能自己 new 一个 - 用
context.WithDeadline时，子协程的 deadline 是基于系统时钟的绝对时间，不是相对父协程剩余时间；若需“最多再跑 2 秒”，必须用WithTimeout而非WithDeadline - 别在子协程里直接检查
ctx.Err() == context.Canceled来判断是否该退出 —— 应该监听，因为 <code>Err()可能返回nil直到 channel 关闭
最麻烦的地方往往不在启动协程，而在 cleanup：比如子协程已开始写文件但 Context 被 cancel，这时候得靠 defer + os.Remove 或临时标记来保证状态一致。Context 本身不负责资源回收，它只负责发信号。
