recover捕获不到panic的主因是调用位置错误或作用域不匹配：必须在defer声明的匿名函数内直接调用，且defer需在panic前注册；goroutine、延迟加载回调等脱离主执行流的panic无法被外层recover捕获。
defer 中 recover 捕获不到 panic 的常见原因
最常遇到的情况是：recover() 调用位置不对，或者被间接使用。它必须在 defer 声明的匿名函数体内**直接调用**，且该 defer 必须在 panic 触发前已注册。
-
defer func() { r := recover(); ... }()✅ 正确 -
r := recover; defer func() { r() }()❌ 失效，recover被提前赋值 -
defer func() { ... }(); panic("x")✅ 正确（defer在前） -
panic("x"); defer func() { recover() }()❌ 无效，defer注册太晚
尤其在延迟加载场景（如 init() 或首次调用时动态加载配置/插件），如果 panic 发生在 defer 作用域之外（比如嵌套 goroutine 或回调函数里），recover 就完全不起作用。
HTTP handler 延迟加载中 panic 的恢复边界
Web 框架里常见的“延迟加载”是指中间件、路由匹配、或模板渲染等环节在请求处理链中才真正执行。此时 panic 若发生在 next.ServeHTTP() 内部，recover 中间件仍能捕获——但前提是它包裹了整个调用链。
- 必须把
defer+recover放在next.ServeHTTP(w, r)之前，否则注册无效 - 若延迟加载逻辑启动了新 goroutine（如异步日志上报、缓存预热），那个 goroutine 内的
panic不会被外层中间件捕获 -
w.Header().WasWritten()要检查，避免http.Error()触发二次 panic
例如：gee.Context.String() 内部若因模板未注册 panic，只要它在 handler 执行路径上，外层 recover 中间件就能兜住；但如果它被丢进 go func() { ... }()，那就彻底脱离恢复范围。
立即学习“go语言免费学习笔记（深入）”；
自定义 panic 类型控制恢复粒度
延迟加载常伴随初始化失败（如配置解析、DB 连接），这类错误是否该 recover，取决于你是否认为服务还能“带病运行”。Go 不建议用 panic 处理业务错误，但初始化阶段的致命失败可以明确标记。
- 用结构体或带前缀的字符串区分：比如
panic(&configLoadError{...})或panic("user: invalid config") - 在
recover中判断类型：if p, ok := r.(string); ok && strings.HasPrefix(p, "user:")，只恢复这类 panic - 对
runtime error: index out of range或nil pointer dereference这类系统级 panic，不建议 recover，应让程序崩溃并暴露问题
这能避免把本该终止的初始化失败掩盖成 500 错误，导致后续请求持续失败却无感知。
goroutine 内延迟加载的 panic 必须独立 recover
延迟加载逻辑如果跑在单独 goroutine 里（比如后台加载证书、热更新路由表），它的 panic 和主 handler 完全无关。每个 goroutine 的 panic 只能由它自己内部的 defer + recover 捕获。
- 不能指望外层中间件或全局 init 函数兜底
- 典型写法：
go func() { defer func() { if r := recover(); r != nil { log.Printf("bg loader panic: %v", r) } }(); doLazyLoad() }() - 注意：goroutine 中 recover 后无法向 HTTP 响应写入内容，只能记录日志或触发告警
这是最容易忽略的一点——你以为加了 recover 中间件就万事大吉，结果后台加载器 panic 了，服务看似正常，但功能已残缺，且没有任何可观测线索。
