应使用 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 层统一转成用户友好的响应，不再向下传递包装链
