17370845950

Go 明确区分 error 和 panic：业务错误必须显式返回 error 并由调用方处理，panic 仅用于致命异常；统一错误响应应通过自定义 HandlerFunc + 中间件实现，而非 recover 捕获 error。

Go 没有 try/catch，panic 也不是用来捕获业务错误的

Go 的设计哲学明确区分「错误（error）」和「异常（panic）」。业务逻辑失败（如数据库查不到、参数校验不通过）必须返回 error 值，由调用方显式判断；而 panic 仅用于程序无法继续运行的致命状态（如空指针解引用、切片越界）。试图用 recover 在中间件或 defer 中“统一捕获所有 error”是无效且危险的——error 不会触发 panic，自然也无法 recover。

HTTP 服务中统一错误响应：用中间件包装 handler

常见需求是让所有 HTTP handler 返回标准错误格式（如 {"code": 500, "message": "xxx"}），避免每个 handler 重复写 w.WriteHeader() 和 JSON 序列化。关键在于把 handler 封装成能返回 error 的函数，并在中间件里统一处理：

func ErrorHandler(next http.HandlerFunc) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        defer func() {
            if err := recover(); err != nil {
                http.Error(w, "Internal Server Error", http.StatusInternalServerError)
                log.Printf("PANIC: %v", err)
            }
        }()

        if err := handleWithErr(next, w, r); err != nil {
            w.Header().Set("Content-Type", "application/json")
            w.WriteHeader(http.StatusInternalServerError)
            json.NewEncoder(w).Encode(map[string]string{"error": err.Error()})
        }
    }
}

func handleWithErr(fn http.HandlerFunc, w http.ResponseWriter, r *http.Request) error {
    // 用 channel 捕获 handler 内部 error（需改造 handler 签名）
    // 更实际的做法：定义自定义 handler 类型
}

// 推荐方式：定义统一 handler 类型
type HandlerFunc func(http.ResponseWriter, *http.Request) error

func WrapHandler(h HandlerFunc) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        if err := h(w, r); err != nil {
            w.Header().Set("Content-Type", "application/json")
            w.WriteHeader(http.StatusInternalServerError)
            json.NewEncoder(w).Encode(map[string]interface{}{
                "code":    500,
                "message": err.Error(),
            })
            return
        }
    }
}

• WrapHandler 要求所有业务 handler 实现 HandlerFunc 接口（返回 error），而非原生 http.HandlerFunc
• 中间件只处理 error，不碰 panic；真正的 panic 仍需 defer/recover

  

  单独兜底（仅限顶层）
• 不要在中间件里尝试 recover 业务 error——它根本不会 panic

CLI 或后台任务中统一错误退出：用 main 函数集中判断

命令行工具或定时任务通常只有一个入口点，最简单可靠的统一错误处理就是让所有逻辑返回 error，并在 main 中统一处理：

func main() {
    if err := run(); err != nil {
        fmt.Fprintf(os.Stderr, "ERROR: %v\n", err)
        os.Exit(1)
    }
}

func run() error {
    cfg, err := loadConfig()
    if err != nil {
        return fmt.Errorf("loading config: %w", err)
    }

    db, err := openDB(cfg.DBURL)
    if err != nil {
        return fmt.Errorf("connecting to DB: %w", err)
    }
    defer db.Close()

    if err := processItems(db); err != nil {
        return fmt.Errorf("processing items: %w", err)
    }

    return nil
}

• 所有子函数都返回 error，用 %w 包装形成错误链，便于日志追踪
• 不依赖全局变量或注册机制——Go 鼓励显式错误传递，隐式“全局捕获”反而破坏可读性和测试性
• 若需不同错误映射为不同退出码，可在 main 中用 errors.As 类型断言区分

不要用全局 error hook，init 或包级变量无法替代显式错误流

有人试图在 init 函数中注册一个全局错误处理器，或用包级 var ErrHandler func(error)，这在 Go 中既不可靠也不必要：

• Go 的 error 是值，不是事件——它不会自动“抛出”到某个中心点
• 包级变量导致隐式依赖，难以 mock 测试，且并发下可能被意外覆盖
• HTTP handler、goroutine、defer、callback 等不同上下文对错误的处理策略本就不同，强行统一反而增加耦合
• 真正需要“统一”的是错误格式（如结构体字段）、日志记录方式（如加 traceID）、或退出行为（如 CLI），而不是捕获动作本身

最常被忽略的一点：错误处理的粒度必须匹配上下文。HTTP handler 里返回 400 还是 500，取决于错误是否由客户端引起；而 CLI 里所有错误都该输出到 stderr 并 exit 1——这些决策没法交给一个“全局钩子”自动完成。