不会。log.Fatal 调用 os.Exit(1) 直接终止程序,不捕获 panic,defer 中的 recover 也因强制退出而失效;正确做法是用 log.Error 或 zap.Error 记录可恢复错误并返回,仅在不可恢复时才 os.Exit 或让 panic 冒泡。
不会。log.Fatal 本身会调用 os.Exit(1),它不捕获 panic,而是直接终止程序;panic 也不会被普通 log.Print 系列函数拦截。如果你在 defer 中 recover,但又用了 log.Fatal,recover 就失效了——因为 log.Fatal 强制退出,defer 都来不及执行完。
正确做法是:遇到可恢复错误,用 log.Error(如 zap 或 logrus)或 log.Printf 记录,再显式返回错误;真正不可恢复时,才考虑 os.Exit 或让 panic 向上冒泡。
log.Fatal = log.Print + os.Exit(1),无 recover 机会recover() + 自定义日志写入(比如写到文件或 sentry)log 不区分 error/info/warn 级别,建议换用 zap 或 zerolog
要看错误类型。业务校验失败(如 email format invalid)通常不需要 stacktrace;而未预期的 panic、空指针、接口断言失败等,必须带 stacktrace 才能定位。
zap 提供 zap.Stack() 和 zap.NamedError(),后者会自动提取 error 实现的 StackTrace() 方法(如 github.com/pkg/errors 或 Go 1.17+ 的 errors.WithStack 封装)。
if err != nil {
logger.Error("failed to process user",
zap.String("user_id", userID),
zap.Error(err), // 如果 err 是 pkg/errors.Wrap 封装的,会自动带 stack
zap.String("stage", "decode"),
)
}
zap.Stack(),它开销大且信息冗余zap.Error(err),依赖 error 类型自身是否携带 tracefmt.Sprintf("%+v", err) 写进日志字段——会丢失结构化能力优先用 fmt.Errorf("%w", err)。Go 1.13 引入的 %w 是语言原生支持,errors.Is / errors.As 能正常工作,且无额外依赖。
github.com/pkg/errors 的 Wrap 在 Go 1.13+ 已不推荐,它返回的 error 不完全兼容标准库的 unwrap 行为(比如嵌套多层时 errors.Unwrap 可能漏掉中间层)。
// ✅ 推荐:原生语义清晰,工具链友好
err := doSomething()
if err != nil {
return fmt.Errorf("failed to initialize config: %w", err)
}
// ❌ 不推荐:pkg/errors.Wrap 在 go 1.20+ 中与 vet 冲突,且 stacktrace 格式不统一
// return errors.Wrap(err, "failed to initialize config")
%w,否则 errors.Is(err, fs.ErrNotExist) 会失败%w 和 %s 包装同一错误链,会导致 unwrap 中断不要。HTTP handler 属于边界层,错误应降级为用户可读提示(如 {"error": "invalid request"}),日志只需记录关键上下文 + 错误摘要 + trace ID,stacktrace 留给后端服务内部错误(如 DB 查询失败、RPC 超时)。
典型反模式:logger.Error("http handler panic", zap.Any("err", r)) —— 这会把整个 http.Request 结构体全打出来,含 body、headers、甚至 cookies,既慢又危险。
zap.String("trace_id", reqID) + zap.Error(err) 即可http.Error(w, err.Error(), http.StatusIntern
alServerError),应返回泛化错误码