Go语言错误日志处理技巧分享

你在学习Golang相关的知识吗？本文《Go错误日志记录与处理技巧》，主要介绍的内容就涉及到，如果你想提升自己的开发能力，就不要错过这篇文章，大家要知道编程理论基础和实战操作都是不可或缺的哦！

不会。log.Fatal 调用 os.Exit(1) 直接终止程序，不捕获 panic，defer 中的 recover 也因强制退出而失效；正确做法是用 log.Error 或 zap.Error 记录可恢复错误并返回，仅在不可恢复时才 os.Exit 或让 panic 冒泡。

Go 中 panic 会被 log.Fatal 捕获吗

不会。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 机会
• 想记录 panic 日志？必须配合 recover() + 自定义日志写入（比如写到文件或 sentry）
• 标准库 log 不区分 error/info/warn 级别，建议换用 zap 或 zerolog

用 zap 记录错误时要不要带 stacktrace

要看错误类型。业务校验失败（如 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 类型自身是否携带 trace
• 避免手动 fmt.Sprintf("%+v", err) 写进日志字段——会丢失结构化能力

error 包装时该用 errors.Wrap 还是 fmt.Errorf %w

优先用 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 中断
• 如果要加 context 字段（如请求 ID），用独立日志字段，而不是塞进 error message 里

HTTP handler 中错误日志要不要打 full stack

不要。HTTP handler 属于边界层，错误应降级为用户可读提示（如 {"error": "invalid request"}），日志只需记录关键上下文 + 错误摘要 + trace ID，stacktrace 留给后端服务内部错误（如 DB 查询失败、RPC 超时）。

典型反模式：logger.Error("http handler panic", zap.Any("err", r)) —— 这会把整个 http.Request 结构体全打出来，含 body、headers、甚至 cookies，既慢又危险。

• handler 中 panic 捕获后，用 zap.String("trace_id", reqID) + zap.Error(err) 即可
• 敏感字段（如 Authorization header、password 字段）必须过滤，不能直接 log struct
• 生产环境禁用 http.Error(w, err.Error(), http.StatusInternalServerError)，应返回泛化错误码

日志不是 dump，错误也不是越详细越好。真正难的是判断哪一层该留 trace、哪一层该脱敏、哪一层该丢弃——这些决策藏在 error 的构造方式和日志写入位置里，不在工具本身。

今天关于《Go语言错误日志处理技巧分享》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！