Golang异常捕获：中间件与HTTP恢复详解

在Go HTTP服务中，panic不会被自动捕获，一旦发生便会直接导致整个服务崩溃，因此必须在每个请求对应的goroutine入口处——即中间件的ServeHTTP方法中，通过defer+recover进行手动兜底；这种设计并非疏漏，而是Go官方对“panic代表严重编程错误”的明确立场，拒绝用运行时拦截掩盖问题；实践中应实现标准http.Handler接口的Recovery中间件，确保recover后主动调用WriteHeader(500)、脱敏写入响应体、记录上下文并上报告警，同时严格避免继续执行原handler或二次调用引发连锁故障——因为recover仅能阻止goroutine退出，无法回滚已发生的副作用，其核心价值在于保服务可用性而非修复请求，而全局panic防护还需区分HTTP请求goroutine、main goroutine及后台任务，各自采取针对性策略。

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 就完事，否则客户端卡住等超时。

• 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 是唯一有效的拦截点，别的地方加都没用。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Golang异常捕获：中间件与HTTP恢复详解》文章吧，也可关注golang学习网公众号了解相关技术文章。