Go错误处理如何记录日志_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 hand

ler 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 的构造方式和日志写入位置里，不在工具本身。

# word # git # go # github # cookie # 工具 # 后端 # ai # 标准库 # print # String # 封装 # format # Error # printf # 结构体 # 指针 # 接口 # Struct # 空指针 # http # rpc # sentry # 的是 # 可恢复 # 中间层 # 不需要 # 你在 # 只需 # 用了 # 要看 # 自定义 # 要对

相关栏目：【网站优化151355 】【网络推广146373 】【网络技术251813 】【 AI营销90571 】