Go语言怎么做Recovery中间件_Go语言panic恢复中间件教程【进阶】

大家好，我们又见面了啊~本文《Go语言怎么做Recovery中间件_Go语言panic恢复中间件教程【进阶】》的内容中将会涉及到等等。如果你正在学习Golang相关知识，欢迎关注我，以后会给大家带来更多Golang相关文章，希望我们能一起进步！下面就开始本文的正式内容~

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 执行之前生效，否则包不到实际业务逻辑

panic 恢复这件事，难点不在代码几行，而在搞清 panic 发生在哪条 goroutine、被谁先拦截、以及是否真该 recover —— 很多时候，让 panic 真实暴露反而是更安全的选择。

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~