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 中统一处理：
ImageMagick 批处理处理器
下载
使用 ImageMagick 的 convert 和 mogrify 命令进行批量图像处理，支持调整大小、裁剪、水印和格式转换。与 libvips 集成以实现高性能缩略图生成。
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语言免费学习笔记（深入）”；
- Go 的
error是值，不是事件——它不会自动“抛出”到某个中心点 - 包级变量导致隐式依赖，难以 mock 测试，且并发下可能被意外覆盖
- HTTP handler、goroutine、defer、callback 等不同上下文对错误的处理策略本就不同，强行统一反而增加耦合
- 真正需要“统一”的是错误格式（如结构体字段）、日志记录方式（如加 traceID）、或退出行为（如 CLI），而不是捕获动作本身
最常被忽略的一点：错误处理的粒度必须匹配上下文。HTTP handler 里返回 400 还是 500，取决于错误是否由客户端引起；而 CLI 里所有错误都该输出到 stderr 并 exit 1——这些决策没法交给一个“全局钩子”自动完成。
