如何在Golang中为错误添加上下文信息_Golang错误上下文扩展与追踪技巧

应使用 fmt.Errorf 的 %w 动词包装错误以保留原始错误链，支持 errors.Is 和 errors.As 向下查找；避免用 %v/%s 或字符串拼接，防止丢失类型与堆栈信息。

用 fmt.Errorf 的 %w 动词包装错误，保留原始错误链

go 1.13 引入了错误包装（error wrapping），核心是让新错误能“包裹”旧错误，从而支持 errors.Is 和 errors.As 向下查找。关键不是拼接字符串，而是用 %w 动词：

if err != nil {     return fmt.Errorf("failed to read config file: %w", err) }

不加 %w 就只是普通字符串错误，丢失原始类型和堆栈线索；用 %v 或 %s 更是彻底断链。
常见错误：在日志里直接 log.printf("err: %v", err) —— 这会调用 Error() 方法，但无法展开底层错误。应改用 fmt.printf("%+v", err)（需配合 github.com/pkg/errors 或 Go 1.20+ 的 errors.Print）才能看到完整链。

在关键路径上用 errors.WithStack（第三方）或手动注入调用点

标准库不提供堆栈捕获，所以仅靠 %w 包装仍缺位置信息。若需快速定位出错函数/行号，推荐 github.com/pkg/errors：

import "github.com/pkg/errors" // ... if err != nil {     return errors.WithStack(err) // 自动捕获当前调用栈 }

注意：它只在第一次包装时记录栈，后续 %w 不会覆盖；且与标准库 fmt.Errorf 混用时要小心——pkg/errors 的 Wrap 等价于 fmt.Errorf("%w", ...)，但它的 WithStack 是额外能力。
替代方案（不用第三方）：用 runtime.Caller 手动构造带位置的错误，但成本高、易误用，仅建议在极少数入口函数做一次。

用 errors.Unwrap 和 errors.Is 安全地检查底层错误类型

不要用 strings.Contains(err.Error(), "permission denied") 做判断——这脆弱、低效、且无法区分同名但不同源的错误。
正确方式是利用错误链语义：

if errors.Is(err, os.ErrPermission) {     // 处理权限问题 } if errors.As(err, &os.PathError{}) {     // 提取路径和操作信息 }

errors.Is 会逐层 Unwrap 直到匹配或返回 nil；errors.As 则尝试将任意一层错误转换为目标类型。
注意：只有用 %w 或实现了 Unwrap() error 方法的错误才可被遍历。自定义错误结构体若想参与链式检查，必须显式实现 Unwrap 方法。

避免在中间层重复包装，防止错误链过长或语义模糊

错误包装不是越多越好。典型反模式：

// ❌ 多层无意义包装 func A() error { return fmt.Errorf("A failed: %w", B()) } func B() error { return fmt.Errorf("B failed: %w", C()) } func C() error { return fmt.Errorf("C failed: %w", os.Open(...)) }

这样最终错误变成 “A failed: B failed: C failed: open /x: permission denied”，既冗余又掩盖真实原因。
更合理的做法：

• 底层函数（如 I/O、DB 调用）不包装，直接返回原始错误
• 业务逻辑层按需添加**有意义的上下文**，例如 “failed to load user profile for ID=123”
• http handler 层统一转成用户友好的响应，不再向下传递包装链

真正需要追踪的，是“哪里出了问题”，而不是“谁调了谁”。