Go HTTP服务中panic需在中间件的ServeHTTP里用defer recover捕获，因每个请求在独立goroutine中运行，仅此处能覆盖全部handler；recover后须调用WriteHeader(500)并脱敏写响应，不可继续执行原handler。
Go HTTP 服务里 panic 不会自动恢复，http.Serve 会直接崩溃
Go 的 http.Serve 默认不捕获 handler 中的 panic，一旦某个请求触发 panic，整个服务就挂了——这不是“异常没处理”，而是 Go 故意不兜底。官方认为 panic 是编程错误，不该靠 runtime 拦截来掩盖。
所以必须手动加 recover，而且得在每条请求路径入口处做，不能只靠 defer+recover 包一层 main 函数。
- 中间件是最自然的位置：所有请求都经过它，
defer recover()放在这里才真正覆盖全部 handler - 别在
http.HandleFunc里每个函数内部写 recover——重复、易漏、难维护 - 注意 recover 只对当前 goroutine 有效；HTTP server 启动后每个请求都在独立 goroutine 里跑，所以 recover 必须在 handler 执行链里
用 http.Handler 接口实现 Recovery 中间件，别用闭包套闭包
很多人写成 func Recovery(next http.HandlerFunc) http.HandlerFunc，看似简洁，但实际掩盖了类型细节，导致日志、状态码、响应体控制变弱。直接实现 http.Handler 接口更可控，也更容易注入依赖（比如 logger、metrics）。
关键点是：recover 后要主动写 response，不能只 log 就完事，否则客户端卡住等超时。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- recover 后必须调用
w.WriteHeader(500)，否则默认 200，前端可能解析空响应失败 - 别用
fmt.Fprint(w, ...)直接输出 panic 信息——生产环境要脱敏，至少过滤掉 stack trace 中的文件路径和行号 - 如果用了第三方 router（如
gorilla/mux或chi），它们自带 Recovery 中间件，但默认行为未必符合你的日志格式或错误上报逻辑，建议重写或 wrap
func (r *recoveryHandler) ServeHTTP(w http.ResponseWriter, req *http.Request) {
defer func() {
if err := recover(); err != nil {
w.WriteHeader(500)
// 脱敏处理 err，再写入 w
log.Printf("panic recovered: %v", err)
}
}()
r.next.ServeHTTP(w, req)
}
recover 之后不能继续执行原 handler，但可以做 cleanup 和上报
recover 只是让 goroutine 不退出，它不会“回滚”已发生的副作用。比如 panic 前已经写了部分响应头、发了 DB 更新、发了 MQ 消息——这些都不会自动撤销。
所以 Recovery 的作用不是“让请求成功”，而是“不让服务崩”，同时给你机会记录上下文、通知告警、清理资源。
- 不要在 recover 后 try 再次调用原 handler——这等于把错误逻辑又跑一遍，大概率二次 panic
- 可以在 defer 里加 context.Cancel，关闭关联的子 goroutine 或 timeout channel
- 如果 handler 里开了 goroutine 做异步任务（比如写日志、发监控），recover 无法影响它；这类 goroutine 自己得有 panic 防御，或者用
sync.Once确保上报只做一次
全局 panic 捕获要区分场景：http.Server vs main goroutine
HTTP 服务里有两种 panic 场景：一种是 request goroutine 里的（上面说的），另一种是 main goroutine 里的——比如 TLS 配置错、端口被占、http.ListenAndServeTLS 启动失败。后者 recover 不了，只能靠启动校验和进程级监控。
-
http.Server的ErrLog字段可捕获底层 listener 错误，但它不处理 handler panic - main goroutine 的 panic 可以用
signal.Notify+os.Exit做 graceful shutdown，但无法 recover - 真正需要全局兜底的是：非 HTTP 的后台 goroutine（比如定时任务、消息消费者），它们得各自加 defer recover，没有统一入口
最常被忽略的一点：recover 只能捕获当前 goroutine 的 panic，而 Go 的 HTTP server 启动后，所有 handler 都在新 goroutine 里跑——所以中间件里的 defer recover 是唯一有效的拦截点，别的地方加都没用。
