Go中闭包捕获context.Context是安全的，因其不可变且线程安全；应捕获已构造好的ctx实例，每次调用时从请求提取并派生子上下文，配合defer cancel()确保资源释放，避免全局复用或提前固化带deadline的ctx。
闭包怎么捕获并携带 context.Context
Go 里 context.Context 本身不可变，闭包不能“修改”它，但可以捕获当前值并在后续调用中复用或派生新上下文。关键不是保存状态，而是保存对某个 context.Context 实例的引用，并在需要时传给下游函数（比如 http.HandlerFunc、database/sql 查询等）。
常见错误是把 context.WithCancel 或 context.WithTimeout 的返回值直接存进闭包，却忘了关闭 cancel 函数，导致 goroutine 泄漏；或者误以为闭包能“自动继承”父上下文的 deadline/cancel，其实必须显式传递。
- 闭包内应只捕获已构造好的
ctx变量，不建议在闭包体内调用context.WithXXX—— 容易漏 defer cancel - 若需派生子上下文（如加 timeout），应在闭包调用时做，而不是提前固化一个带 deadline 的 ctx（deadline 会随时间流逝失效）
- 典型场景：HTTP handler 中提取
req.Context()，封装成带业务逻辑的闭包，再传给中间件或 service 层
写一个带 context 的 HTTP handler 闭包
比如你有一组路由共享同一套 auth 和 tracing 逻辑，想用闭包封装，同时确保每个请求都带自己的 req.Context()。
错误写法：
var badHandler = func(w http.ResponseWriter, r *http.Request) {
// ❌ 错：闭包外捕获了全局 ctx，所有请求共用同一个
ctx := context.Background()
service.Do(ctx, r.URL.Path)
}
正确写法：
func makeHandler(service Service) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
// ✅ 对每个请求取自己的 req.Context()
ctx := r.Context()
// 可选：派生带超时的子 ctx
ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
defer cancel()
service.Do(ctx, r.URL.Path)
}
}
- 闭包本身不保存 ctx，而是每次调用时从
r提取，保证隔离性 - 派生的
ctx和cancel必须在 handler 返回前调用defer cancel()，否则 timeout 后资源不释放 - 如果 service 方法内部还要加 value，用
context.WithValue(ctx, key, val)，但 key 必须是自定义类型（避免字符串冲突）
闭包里存 context.Value 怎么安全传参
用 context.WithValue 传业务参数（如 user ID、trace ID）很常见，但闭包容易误存“原始 key”，导致不同请求覆盖或读错值。
立即学习“go语言免费学习笔记（深入）”；
典型坑：
// ❌ 危险：用 string 作 key，多个包可能撞 key
ctx := context.WithValue(r.Context(), "user_id", userID)
// ✅ 推荐：定义私有类型作 key
type userIDKey struct{}
ctx := context.WithValue(r.Context(), userIDKey{}, userID)
- 闭包内若要复用某个 value，应先提取再存为局部变量，而不是反复 call
ctx.Value(key) - 不要把带 value 的 ctx 存到全局变量或 long-lived 闭包里 —— 值会过期或污染其他请求
- 如果闭包用于 goroutine，必须传入当前 ctx，不能依赖外部捕获的 ctx（可能已被 cancel）
为什么 defer cancel() 不能放在闭包外
闭包生命周期 ≠ 请求生命周期。如果你在闭包定义时就调用 context.WithCancel 并 defer cancel，cancel 会在闭包创建时立刻执行（或根本没机会执行），导致所有后续调用拿到已 cancel 的 ctx。
示例：
// ❌ 错：cancel 在闭包构造时就 defer，实际 never run 或立即 run
func badClosure() func() {
ctx, cancel := context.WithCancel(context.Background())
defer cancel() // ← 这里 cancel 立即生效！
return func() {
select {
case <-ctx.Done():
log.Println("already cancelled")
}
}
}
- cancel 必须和 ctx 使用范围一致：ctx 用于哪段逻辑，cancel 就该 defer 在那段逻辑末尾
- HTTP handler、goroutine 入口、数据库查询前后，都是 cancel 的合理位置
- 闭包唯一该做的，是把 ctx 作为参数接收，或从输入（如
*http.Request）中提取，然后按需派生 + defer
真正难的不是语法，是判断 ctx 生命周期边界 —— 它由谁创建、谁取消、在哪一环失效。闭包只是个载体，别让它替你做决策。
