go http服务panic崩溃因recover仅作用于当前goroutine，需在每个handler内部用中间件defer recover；标准库不捕获，应封装func(http.handler)http.handler统一处理并返回500。
Go HTTP 服务 panic 后直接崩溃？用 recover 拦不住
不是 recover 写得不对，而是它只对当前 goroutine 有效。HTTP handler 里 panic，触发的是新 goroutine（由 http.ServeMux 启动），主流程的 defer + recover 根本看不到。
- 必须在每个 handler 执行前、或通过
http.Handler包装器，在 handler goroutine 内部做defer recover() - 不能只在
main()或启动逻辑里 defer —— 那里 recover 不到 handler 的 panic - 标准库
http.DefaultServeMux不做任何 recover，出错就打印堆栈并关闭连接
写一个通用的 Recovery 中间件：别直接改 http.HandlerFunc
中间件本质是函数套函数，把原始 handler 包一层，加 defer/recover 逻辑。关键不是“怎么写”，而是“在哪插、插几层”。
- 推荐封装为
func(http.Handler) http.Handler类型，兼容所有实现了http.Handler接口的对象（包括http.ServeMux、自定义 struct） - 避免只适配
http.HandlerFunc，否则遇到chi.Router或gin.Engine就失效 - recover 后建议返回 500，并记录错误（用
log.Printf或结构化日志库），别静默吞掉
func Recovery(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
defer func() {
if err := recover(); err != nil {
log.Printf("panic recovered: %v", err)
http.Error(w, "Internal Server Error", http.StatusInternalServerError)
}
}()
next.ServeHTTP(w, r)
})
}
recover 捕获不到 context canceled 或 net/http.ErrServerClosed？这是对的
recover 只捕获 panic，不处理 error 返回值。像 context.DeadlineExceeded、net/http.ErrServerClosed 是正常 error 流程，不是 panic，中间件里不该、也不能用 recover 拦。
- 混淆 panic 和 error 是常见误区；前者是运行时异常（如 nil pointer dereference），后者是控制流的一部分
- 如果发现某些错误总伴随 panic，大概率是业务代码里写了
panic(err)，应改为return err或显式 http.Error - 想统一处理 error？该用 handler 内部的 error 判断逻辑，或结合 middleware 配合
ResponseWriter包装器
日志里看到 panic 但没进 recovery？检查是否用了第三方路由库的 panic 捕获机制
像 gin、echo、chi 都自带 Recovery 中间件，且默认开启。如果你自己又写了一层，可能被绕过，或者 panic 被上游提前 recover 了，导致你自己的日志没打出来。
- 查文档确认该框架是否已内置 recovery（例如
gin.Default()自带gin.Recovery()） - 禁用框架默认 recovery，再用自己的，避免重复或冲突
- 注意中间件注册顺序：你的 recovery 必须在路由匹配之后、handler 执行之前生效，否则包不到实际业务逻辑
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
