Go中返回有意义错误的核心是保留原始错误、添加精准上下文、支持程序化判断，应使用fmt.Errorf配合%w包装，避免字符串拼接或%v，确保errors.Is和errors.As正常工作。
Go 中返回有意义的错误信息，核心不是“写得更长”，而是“保留原始错误 + 添加精准上下文 + 支持程序化判断”。否则日志里全是模糊字符串，线上出问题时只能靠猜。
用 fmt.Errorf 配合 %w 包装错误，而不是 %v 或拼接字符串
直接 fmt.Errorf("failed to read config: %v", err) 会丢失原始错误类型，导致后续无法用 errors.Is 判断是否是 os.ErrNotExist；而只写 "failed to read config" 又丢掉了底层原因。
-
%w是唯一能保留错误链（error chain）的方式，让errors.Is和errors.As正常工作 - 包装时添加的上下文要具体：比如是哪个文件、哪个用户 ID、哪次 HTTP 方法，而不是笼统的“操作失败”
- 避免多层重复包装：A → B → C 都用
%w没问题，但 A → B（%w）→ C（%v）就断链了
示例：return fmt.Errorf("loading user profile for uid=%d failed: %w", uid, err)
什么时候该定义自定义错误类型，而不是用 fmt.Errorf
当你需要在错误中携带结构化数据（如状态码、重试建议、字段名），或希望上层能做精确行为分支（比如自动重试、跳过、告警）时，才值得定义结构体错误。
立即学习“go语言免费学习笔记（深入）”；
- 常见场景：API 响应错误（含 HTTP 状态码）、校验失败（需返回具体字段）、数据库约束冲突（需区分唯一键 vs 外键）
- 必须实现
Error() string方法；若需支持errors.As提取，字段不能是私有（如Code int而非code int） - 别为了“看起来专业”而定义一堆空壳错误类型——多数业务错误用
fmt.Errorf+%w就够了
示例：
type ValidationError struct { Field string; Msg string }
func (e *ValidationError) Error() string { return fmt.Sprintf("validation error on '%s': %s", e.Field, e.Msg) }
用 errors.Is 和 errors.As 替代字符串匹配或类型断言
写 if strings.Contains(err.Error(), "no such file") 或 _, ok := err.(*os.PathError) 是危险且脆弱的——一旦底层错误实现变更或包装方式调整，逻辑就失效。
-
errors.Is(err, os.ErrNotExist)能穿透任意层%w包装，安全可靠 -
errors.As(err, &pathErr)可提取任意位置的*os.PathError，哪怕它被包了三层 -
标准库预定义错误（如
os.ErrNotExist、sql.ErrNoRows）优先用errors.Is；自定义错误优先用errors.As
示例：
if errors.Is(err, os.ErrNotExist) { return handleMissingFile() }
var pathErr *os.PathError
if errors.As(err, &pathErr) { log.Warn("bad path", "path", pathErr.Path) }
别在中间层吞掉错误或只打日志不返回
常见反模式：if err != nil { log.Printf("warn: %v", err); return nil } —— 这等于把错误“静音”，调用方收不到任何失败信号，可能继续用零值执行，最终 panic 或数据错乱。
- 中间函数的职责是传播错误，不是终结错误；日志记录通常只应在最外层（如 HTTP handler 或 CLI 入口）做一次
- 如果真要忽略某个错误（极少数情况，如
os.Remove删除临时文件失败），必须显式注释理由，且确保不影响主流程 -
工具如
errcheck可帮你发现未处理的error返回值
真正容易被忽略的一点：错误包装不是“越多越好”，而是“刚好够用”。加太多上下文反而让关键信息被淹没；不加上下文又让排查变成考古。平衡点在于——每个包装层只回答一个问题：“这一步，到底哪里出了问题？”
