登录
首页 >  Golang >  Go教程

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

时间:2026-05-05 20:00:41 188浏览 收藏

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

Go HTTP服务panic崩溃因recover仅作用于当前goroutine,需在每个handler内部用中间件defer recover;标准库不捕获,应封装func(http.Handler)http.Handler统一处理并返回500。

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

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.Routergin.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.DeadlineExceedednet/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 捕获机制

ginechochi 都自带 Recovery 中间件,且默认开启。如果你自己又写了一层,可能被绕过,或者 panic 被上游提前 recover 了,导致你自己的日志没打出来。

  • 查文档确认该框架是否已内置 recovery(例如 gin.Default() 自带 gin.Recovery()
  • 禁用框架默认 recovery,再用自己的,避免重复或冲突
  • 注意中间件注册顺序:你的 recovery 必须在路由匹配之后、handler 执行之前生效,否则包不到实际业务逻辑
panic 恢复这件事,难点不在代码几行,而在搞清 panic 发生在哪条 goroutine、被谁先拦截、以及是否真该 recover —— 很多时候,让 panic 真实暴露反而是更安全的选择。

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

资料下载
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>