判断逻辑错误还是系统错误，关键看错误来源和构造方式：系统错误多来自标准库并带具体类型（如*os.PathError），逻辑错误是自定义业务校验失败（如ErrInvalidUserID），不包装底层error。
怎么判断一个 error 是逻辑错误还是系统错误
Go 里 error 接口本身不带类型标识，所以不能靠 == nil 或 fmt.Sprintf("%v", err) 直接区分——你看到的只是字符串描述，背后可能是文件没权限、网络超时，也可能是用户传了负数 ID。关键看错误来源和构造方式。
系统错误通常来自标准库（比如 os.Open、http.Do），本质是底层 syscall 失败，往往带 *os.PathError、*net.OpError 这类具体类型；逻辑错误是你自己写的业务校验失败，比如 ErrInvalidUserID，一般用 errors.New 或 fmt.Errorf 构造，不包装底层 error。
- 用
errors.Is判断是否属于某类系统错误（如errors.Is(err, os.ErrNotExist)） - 用
errors.As提取底层错误类型（如var pathErr *os.PathError; errors.As(err, &pathErr)） - 自定义逻辑错误不要用
fmt.Errorf("...: %w", err)包裹系统 error，否则会模糊边界
自定义 error 类型该不该实现 Unwrap 方法
只在你需要“把逻辑错误当系统错误透传”时才实现 Unwrap。比如封装了一个数据库操作函数，内部调用了 db.QueryRow，你想让调用方能用 errors.Is(err, sql.ErrNoRows) 捕获空结果——这时你的自定义 error 就得 Unwrap 底层 sql.ErrNoRows。
但大多数业务逻辑错误（比如 “用户名已存在”、“余额不足”）不该 Unwrap 任何东西：它们不是系统失败的衍生，而是独立的业务断言。加了 Unwrap 反而会让错误链变长，干扰真实问题定位。
立即学习“go语言免费学习笔记（深入）”；
- 需要透传底层系统错误 → 实现
Unwrap并返回对应 error - 纯业务规则失败 → 不实现
Unwrap，或显式返回nil - 用
fmt.Errorf("xxx: %w", underlying)自动带Unwrap，但要确认这是你想要的行为
为什么 errors.Is 和 errors.As 在嵌套 error 里容易失效
因为 errors.Is 和 errors.As 默认只查一层 Unwrap，而实际 error 链可能被多层 %w 包装（比如 fmt.Errorf("handle req: %w", fmt.Errorf("db op: %w", sql.ErrNoRows))）。这时候直接 errors.Is(err, sql.ErrNoRows) 会返回 false。
根本原因不是函数有问题，而是你没控制好包装深度。标准库不会递归展开所有 Unwrap，避免无限循环或性能陷阱。
- 确保关键系统错误（如
os.ErrNotExist）尽量靠近 error 链顶端，别被多层业务包装盖住 - 如果必须深层嵌套，手动循环
Unwrap或用第三方库（如github.com/pkg/errors的Cause）——但 Go 1.13+ 官方方案更推荐扁平化设计 -
fmt.Errorf("msg: %w", err)要谨慎，每加一层%w就多一次间接性，调试时 stack 更难读
log.Print(err) 和 %+v 输出差异很大，该怎么选
log.Print(err) 调用的是 err.Error()，只输出字符串；fmt.Printf("%+v", err) 才会触发 error 的结构体字段展开（包括未导出字段），对排查自定义 error 很有用——比如你能看到 userID 字段值、timestamp 等上下文。
但注意：%+v 对标准库 error（如 *os.PathError）确实显示详细信息，可对纯 errors.New("xxx") 或未导出字段的 struct error 就只是地址或空结构。
- 日志记录错误摘要 → 用
log.Printf("failed: %v", err) - 本地调试、CI 失败分析 → 优先
fmt.Printf("debug: %+v\n", err) - 自定义 error struct 里放关键诊断字段（如
Code string、TraceID string），并确保字段导出（首字母大写）
真正难的不是怎么打日志，是怎么让 error 值本身携带足够诊断信息，而不是依赖字符串拼接。字段比消息重要，类型比字符串可靠。
