如何在Golang中实现错误的集中处理 Go语言中间件错误拦截技巧

go http中间件需在最外层用defer+recover捕获panic，显式写入500响应；应定义appError结构体统一错误格式，按类型设置状态码和响应体；注意recover仅对同goroutine有效，且须确保中间件真正包裹handler。

Go HTTP 中间件怎么捕获 handler panic

Go 的 http.ServeHTTP 不会自动 recover panic，一旦 handler 内部 panic，连接直接断开，还可能泄露敏感堆栈。必须手动加 recover。

• 在中间件最外层用 defer + recover() 捕获 panic，否则它会向上冒泡到 net/http 默认日志逻辑
• 不要只 recover 后 log.Print 就完事——得主动写响应，比如 w.WriteHeader(500) 和 w.Write([]byte("internal Error"))
• 注意：recover 只对当前 goroutine 有效；如果 handler 里启了新 goroutine 并 panic，这个中间件捕不到

如何统一格式化 error 并透传到响应体

原生 error 接口太弱，无法携带状态码、错误码、调试信息。直接返回 err.Error() 会导致前端无法区分是参数错还是服务挂了。

• 定义结构体实现 error 接口，比如 type AppError Struct { Code int `json:"code"` Msg String `json:"msg"` Debug string `json:"debug,omitempty"` }
• 在中间件里判断 err 是否为 *AppError，是则取 .Code 设为 HTTP 状态码，.Msg 返回给前端
• 开发环境可加 .Debug 字段输出 runtime/debug.Stack()，但生产环境必须关掉

为什么 defer recover 有时不生效

不是写了 defer 就万事大吉。常见失效场景比想象中多。

• 中间件没真正 wrap 到最终 handler：比如用了 http.HandleFunc 直接注册，绕过了你写的中间件链
• panic 发生在 defer 语句之后、handler 函数 return 之前——但 recover 必须在同一个函数内且在 panic 之前声明
• 用了第三方路由库（如 gin、echo），它们自带 panic recovery，你的中间件可能被跳过或执行顺序不对；查清它们的 middleware 执行时机再决定是否叠加

要不要在中间件里重试或降级

别做。HTTP 中间件不是容错编排层。

立即学习“go语言免费学习笔记（深入）”；

• 重试要分幂等性：GET 可重试，POST/PUT 重试可能造成重复下单
• 降级逻辑（比如 fallback 到缓存）应该放在业务 handler 内部，而不是中间件里——中间件不知道该降级成什么
• 真要统一兜底，也只限于返回预设的静态错误页或 JSON，别动业务状态

事情说清了就结束。最常漏掉的是：recover 后没显式写响应头和 body，导致客户端卡住等待超时；还有就是把业务错误和系统 panic 混在一起处理，结果 400 参数错也被当成 500 上报。