context.Context 不参与 panic 捕获或恢复，panic 只能在同 goroutine 的 defer 中用 recover 处理；子 goroutine panic 不会传播到父 goroutine，需通过 channel 等显式同步；HTTP 中间件是加 recover 的合理位置，但应优先预防而非依赖 recover。
Context传递时Panic不会自动传播或恢复
Go 的 context.Context 本身不参与 panic 捕获或恢复流程。它只是携带取消信号、超时、值等元信息，panic 发生在 goroutine 栈上，和 context 无关。你不能靠 context.WithCancel 或 context.WithTimeout 来“拦截”或“恢复” panic —— 这是常见误解。
recover 必须在同 goroutine 的 defer 中调用才有效
想在 context 传递链中 recover panic，关键不是 context 做什么，而是你如何组织 goroutine 和 defer。典型错误是：在父 goroutine 启动子 goroutine，然后试图在父里 recover 子的 panic —— 这不可能生效。
-
recover()只对当前 goroutine 中刚发生的 panic 有效，且必须在 defer 函数中调用 - 如果子 goroutine 因 panic 崩溃，父 goroutine 不会感知，除非你显式同步（如 channel、WaitGroup + 错误传递）
- context 传递常伴随 goroutine 启动（比如
http.HandlerFunc或自定义 worker），此时每个 goroutine 需独立加 defer+recover
示例（正确姿势）：
go func(ctx context.Context) {
defer func() {
if r := recover(); r != nil {
log.Printf("worker panicked: %v", r)
// 可选：通过 channel 通知主 goroutine
}
}()
// 实际业务逻辑，可能调用其他传 ctx 的函数
doWork(ctx)
}(ctx)
结合 context.Done() 和 panic 恢复的常见组合陷阱
有人试图在 recover 后检查 ctx.Err() 判断是否因取消退出，但要注意：panic 和 context 取消是正交事件。recover 只管 panic，不反映 context 状态；而 <-ctx.Done() 是阻塞等待，不能和 recover 混为一谈。
- 不要在 defer recover 里调用
ctx.Done()并期望它“刚触发”——context 取消可能早于或晚于 panic，无因果关系 - 若需区分“因 cancel 退出”和“因 panic 退出”，应统一用错误通道或返回值传递，例如：
errCh <- fmt.Errorf("panic: %v", r) - 使用
context.WithCancel后主动 cancel，不会引发 panic；但若在 cancel 后继续使用已关闭的资源（如 closed channel），才可能 panic —— 这类 panic 应靠代码健壮性避免，而非依赖 recover
HTTP handler 中 context 与 panic 恢复的真实写法
标准 http.ServeMux 默认不 recover panic，会导致整个 server crash。中间件是加 recover 的合理位置，且要确保它能访问到 request 的 context.Context（即 r.Context()）。
- recover 中可记录日志并带上
ctx.Value()中的 traceID 等调试信息 - 不要在 recover 后尝试继续处理请求（比如写 response）—— responseWriter 可能已失效
- 更安全的做法：recover 后立即返回 500，并用
http.Error或自定义 error writer
简短中间件示意：
func recoverMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
defer func() {
if r := recover(); r != nil {
log.Printf("panic at %s: %v", r.URL.Path, r)
http.Error(w, "Internal Server Error", http.StatusInternalServerError)
}
}()
next.ServeHTTP(w, r)
})
}
真正容易被忽略的是：recover 不是兜底银弹。大量 panic 往往暴露了控制流设计缺陷（比如未检查 channel 关闭、空指针解引用、类型断言失败），优先该做的是预防，而不是在每层都套 defer+recover。context 本身从不抛 panic，但它传递的值如果没做类型校验，下游用 ctx.Value(key).(MyType) 强转就极易 panic —— 这类问题，加 recover 只是掩盖，修复应放在类型安全或默认值兜底上。
