Go 中 recover 无法捕获 context.Cancel 的 panic，因后者不触发 panic 而仅使 ctx.Err() 返回 context.Canceled；需在阻塞点显式检查 ctx.Err() 并主动退出。
Go 中 recover 无法捕获 context.Cancel 的 panic
Go 的 recover 只能捕获由 panic 主动触发的异常，而 context.Cancel 本身不 panic —— 它只是让 ctx.Err() 返回 context.Canceled。常见误区是以为在 defer 里写 recover() 就能“兜住”超时或取消导致的流程中断，结果发现完全没用。
真正需要的是：在关键阻塞点（如 http.Client.Do、time.Sleep、select）显式检查 ctx.Err()，并主动 return 或提前退出。
-
http.NewRequestWithContext比http.NewRequest多一层保障，但最终仍依赖底层 transport 是否尊重 context - 自定义 channel 操作必须配合
select+ctx.Done()，不能只靠recover - 第三方库若未适配 context（比如老版本
database/sql驱动），即使传入带 cancel 的 ctx，也可能忽略
defer + recover 在 HTTP handler 中的实际写法
想在 Gin/echo/fasthttp 等框架中做 panic 恢复，核心不是“加中间件”，而是确保 recover 调用发生在 panic 发生的 goroutine 里 —— 即 handler 函数内部的 defer，而不是中间件函数体里随便 defer。
错误写法：func Recovery() gin.HandlerFunc { return func(c *gin.Context) { defer recover() {...} c.Next() } } —— 这里的 recover 在中间件 goroutine 执行，而 panic 发生在 c.Next() 调用的 handler 里，跨 goroutine 无法捕获。
立即学习“go语言免费学习笔记（深入）”；
- 正确位置：每个 handler 函数开头写
defer func() { if r := recover(); r != nil { /* log & write error */ } }() - 如果用中间件统一处理，必须保证中间件和 handler 在同一 goroutine；Gin 默认满足，但自定义异步逻辑（如 goroutine 启动子任务）需单独 defer
-
recover()返回值是 interface{}，建议用fmt.Sprintf("%v", r)转字符串，避免类型断言失败 panic
Context 超时与 panic 恢复的协作边界
context 负责通知“该停了”，recover 负责兜住“崩了怎么办”。两者不重叠，也不替代。一个典型错误是：在 select 等待 ctx.Done() 时，因 panic 导致 defer 未执行，进而漏掉资源清理。
- 所有可能 panic 的代码段（如 JSON 解析、类型断言、切片越界）前后，都要有明确的
defer清理逻辑 - 不要依赖
recover来释放锁、关闭文件、归还连接 —— 这些必须在 panic 前就安排好defer，因为recover成功后函数才继续执行后续 defer - HTTP handler 中，
recover后应立即返回 500，并确保 response body 已写完，否则 client 可能卡在 read loop
为什么 Gin 的 Recovery 中间件默认不传 context
Gin 的 gin.Recovery() 中间件本身不接收 context 参数，因为它运行在请求生命周期的最外层，其作用域就是当前 HTTP 请求对应的 goroutine。它拿到的 *gin.Context 是框架封装对象，和标准库 context.Context 是两回事。
- 如果你需要在 recovery 逻辑里访问请求上下文信息（如 traceID、user ID），得从
c.Request.Context()显式取，而不是往中间件传参 - 中间件里调用
c.Request.Context().Value("key")是安全的，但注意该 context 在 panic 后仍有效 —— 因为 panic 不影响 context 生命周期 - 别试图在
recover里重启 context（比如 new context.WithCancel），已 cancel 的 context 无法恢复
实际写的时候，最容易被忽略的是：panic 可能发生在你完全没加 defer 的地方，比如第三方库内部、CGO 调用、甚至 runtime 异常（如栈溢出）—— 这些 recover 根本捕获不到。所以别迷信 recover，优先靠 context 控制流程、靠静态检查和测试规避 panic。
