循环中直接传同一context.Context会导致所有goroutine共享取消信号，无法单独控制；且若未调用派生的cancel函数，将引发内存与goroutine泄漏。正确做法是每次迭代用context.WithXXX创建独立子Context，并defer cancel()。
为什么循环里直接传同一个context.Context会出问题
因为context.Context本身不可变，但它的生命周期由父Context控制。如果在循环中启动多个goroutine，并都传入同一个ctx（比如http.Request.Context()），那所有goroutine共享同一取消信号——一旦父Context被取消，全部立刻退出，无法单独控制某次迭代。
更危险的是：若你在循环内调用context.WithTimeout或context.WithCancel却没把返回的cancel函数显式调用，会导致内存泄漏（子Context未释放）和goroutine泄漏（超时未触发清理）。
每次迭代必须创建独立子Context
正确做法是：每轮循环都用context.WithXXX派生新Context，并确保对应cancel被调用。常见组合有：
-
context.WithTimeout(parent, time.Second * 5)：适合单次HTTP请求、数据库查询等有明确耗时上限的场景 -
context.WithDeadline(parent, time.Now().Add(3 * time.Second))：当需要统一截止时间（如整个批处理必须在3秒内完成）时用 -
context.WithCancel(parent)：需手动触发取消，适合需要响应内部状态（如某个子任务失败）的逻辑
关键点：每个cancel必须在本轮goroutine结束前调用，通常用defer cancel()最安全。
立即学习“go语言免费学习笔记（深入）”；
典型错误写法与修复示例
错误示例（共享Context + 忘记cancel）：
for _, id := range ids {
go func() {
// ❌ 所有goroutine共用同一个ctx，且没调用cancel
result, _ := fetch(ctx, id)
results <- result
}()
}正确写法（闭包捕获 + 每次新建 + defer cancel）：
for _, id := range ids {
// ✅ 每次迭代生成独立子Context
childCtx, cancel := context.WithTimeout(ctx, 2*time.Second)
// ✅ 立即绑定到当前goroutine生命周期
go func(id string, cctx context.Context, cancel context.CancelFunc) {
defer cancel() // 保证无论成功失败都释放
result, err := fetch(cctx, id)
if err != nil {
log.Printf("fetch %s failed: %v", id, err)
return
}
results <- result
}(id, childCtx, cancel)
}注意子Context的继承链和性能开销
深层嵌套（比如循环里再开循环，每层都WithCancel）会增加Context树深度，虽然Go runtime能处理，但调试时ctx.Err()溯源困难；而且每次WithValue都会分配新结构体，高频循环中可能引发GC压力。
建议：
- 避免在热循环中频繁调用
context.WithValue，优先用参数传递业务数据 - 若需批量控制，考虑用一个顶层
WithCancel配合sync.WaitGroup，而不是为每个item建子Context - 用
ctx.Value取值前务必做类型断言检查，否则panic不是Context的事，而是你没处理好空值
真正容易被忽略的不是语法，而是cancel的调用时机——它必须和goroutine的生命周期严格对齐，早了任务没跑完就被杀，晚了就一直占着资源。
