Go 语言无全局异常捕获，panic 仅限当前 goroutine；统一错误处理核心是构造、传播、分类与响应策略：用 fmt.Errorf("%w") 链式包装、注入 traceID 等上下文，HTTP 用中间件统一封装错误响应，goroutine 错误需显式收集（如 errgroup），业务错误应定义为可识别类型而非字符串匹配。
Go 语言没有类似 Python 的全局异常捕获机制，panic 可以被 recover 拦截但仅限于当前 goroutine，无法跨 goroutine 捕获错误；所谓“全局错误处理”，本质是**统一错误构造、传播、分类与响应策略**，不是靠一个“兜底 handler”解决所有问题。
如何统一构造和携带上下文的错误
直接用 errors.New 或 fmt.Errorf 生成的错误缺乏类型信息、堆栈和业务标识，不利于日志追踪和分级响应。
推荐使用 github.com/pkg/errors（或 Go 1.13+ 原生 %w）包装错误，并在关键路径注入上下文：
// 示例：HTTP handler 中构造带 traceID 和操作名的错误
func handleUserUpdate(w http.ResponseWriter, r *http.Request) {
ctx := r.Context()
traceID := middleware.GetTraceID(ctx)
if err := updateUser(ctx, userID); err != nil {
// 包装错误，保留原始 error，添加操作语义和 trace
wrapped := fmt.Errorf("failed to update user %s: %w", userID, err)
log.Errorw("user update failed", "trace_id", traceID, "error", wrapped)
// 返回结构化错误响应
writeErrorResp(w, http.StatusInternalServerError, "internal_error", wrapped.Error())
return
}
}
- 避免裸写
return errors.New("xxx")，优先用fmt.Errorf("xxx: %w", err)链式包装 - 在中间件或入口函数中提取
trace_id、user_id、req_id等字段，通过context.WithValue透传并在错误日志中显式打印 - 不要依赖
errors.Is/errors.As判断第三方库返回的原始错误（如sql.ErrNoRows），应在你自己的封装层做一次映射和标准化
如何让 HTTP handler 统一响应错误格式
每个 handler 自己写 if err != nil { ... } 容易遗漏、格式不一致，也不利于统一熔断或审计。
立即学习“go语言免费学习笔记（深入）”；
用函数签名包装 handler，把错误处理逻辑抽离：
type Result struct {
Code int `json:"code"`
Msg string `json:"msg"`
Data interface{} `json:"data,omitempty"`
}
func WithErrorHandling(h func(http.ResponseWriter, *http.Request) error) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
if err := h(w, r); err != nil {
var appErr *AppError
if errors.As(err, &appErr) {
writeJSON(w, appErr.Code, Result{Code: appErr.Code, Msg: appErr.Msg})
return
}
// 非业务错误，统一转为 500
log.Errorw("unhandled error", "error", err, "path", r.URL.Path)
writeJSON(w, http.StatusInternalServerError, Result{
Code: http.StatusInternalServerError,
Msg: "internal server error",
})
}
}
}
// 使用
http.HandleFunc("/api/user", WithErrorHandling(handleUser))
- 不要在
WithErrorHandling中尝试recover()—— Go 的 panic 不该用于控制流，且 recover 无法捕获其他 goroutine 的 panic - 业务错误（如参数校验失败、资源不存在）应定义为可识别的自定义类型（如
*AppError），而非字符串匹配 - HTTP 状态码不应全靠错误内容推断（比如含 “not found” 就返回 404），而应由错误类型或显式字段决定
goroutine 中的错误怎么不丢失
启动新 goroutine 时，如果内部出错却没传递出去，就等于静默失败 —— 这是最常见的“全局错误消失”场景。
必须显式处理三类 goroutine 错误：
- 启动即返回 error 的 goroutine（如
http.ListenAndServe）：必须检查并退出主流程 - 长期运行的 goroutine（如定时任务、消息消费）：用
errgroup.Group或 channel + select 汇报错误 - 短生命周期 goroutine（如异步发邮件）：至少记录错误，必要时重试或告警，不能只写
go sendEmail(...)后不管
示例（使用 errgroup 管理多个后台任务）：
g, ctx := errgroup.WithContext(context.Background())
g.Go(func() error {
return startMetricsServer(ctx)
})
g.Go(func() error {
return startGRPCServer(ctx)
})
g.Go(func() error {
return startHTTPServer(ctx)
})
if err := g.Wait(); err != nil {
log.Errorw("service startup failed", "error", err)
os.Exit(1)
}
真正难的不是“怎么 catch”，而是决定哪些错误该暴露、哪些该吞掉、哪些要重试、哪些要触发告警 —— 这些判断必须落在业务语义层，而不是塞进某个“全局 errorHandler”里自动执行。
