Go错误处理是否需要打印堆栈_Go错误调试技巧

该打印堆栈：panic 默认输出完整堆栈，error 需用 githu

b.com/pkg/errors.Wrap() 包装并以 %+v 格式化，或 Go 1.20+ 的 errors.Print()；生产环境应改用结构化日志记录错误字段。

Go错误是否该打印堆栈？看 panic 还是 error

绝大多数情况下，error 值本身不带堆栈，直接 fmt.Println(err) 或 log.Printf("%v", err) 只会输出错误消息，没有调用链。只有在发生 panic 时，Go 运行时才默认打印完整堆栈。所以「要不要打印堆栈」本质是：你面对的是可恢复的 error，还是已崩溃的 panic。

用 github.com/pkg/errors 或 errors.Join + %+v 打印 error 堆栈

标准库 errors 包（Go 1.13+）支持包装错误，但默认不记录堆栈；要带堆栈，需借助第三方或 Go 1.20+ 的 errors.Print（仅调试用）。更常用的是：

• github.com/pkg/errors 的 errors.Wrap() / errors.WithMessage() 会在包装时捕获当前堆栈
• 用 %+v 格式化输出（不是 %v），才能展开堆栈信息
• Go 1.20+ 可用 errors.Print(err) 直接向 os.Stderr 输出带位置的错误链，适合调试阶段临时插入

import "github.com/pkg/errors"

func risky() error {
    _, err := os.Open("missing.txt")
    return errors.Wrap(err, "failed to open config file")
}

func main() {
    if err := risky(); err != nil {
        fmt.Printf("%+v\n", err) // ✅ 输出含文件名、行号、调用链
    }
}

log.Fatal 和 log.Panic 不会自动加堆栈，别依赖它们调试

log.Fatal() 和 log.Panic() 只是调用 os.Exit(1) 或触发 panic()，但它们本身不增强错误——如果传入的是普通 error，依然没堆栈。常见误用：

• log.Fatal(err) → 只输出错误文本，无上下文
• log.Fatal(errors.Wrap(err, "startup")) → 仍不会自动展开堆栈，除非用 %+v 手动格式化
• 真正需要中止+堆栈时，应显式 log.Printf("%+v", err); os.Exit(1) 或直接 panic(err)（后者会触发运行时堆栈打印）

生产环境避免 %+v，改用结构化日志 + error key

%+v 输出是纯文本，难以被日志系统（如 Loki、ELK）解析；且堆栈信息可能含敏感路径或变量值。生产推荐做法：

• 用 zerolog、zap 等结构化日志库，把错误转为字段：.Err(err).Str("op", "load_config")
• 对关键错误，手动提取并记录 errors.Unwrap() 链中的底层原因和类型
• 启用 GOEXPERIMENT=fieldtrack（Go 1.22+）可让 errors.Is() 更准，辅助分类处理

堆栈不是越多越好——它解决的是「哪里出的错」，而真实瓶颈常在「为什么传了错参数」或「下游返回了什么状态码」。留心 error 是否被多次 Wrap 却没清理，会导致日志膨胀且掩盖原始错误点。