Go中必须显式检查每个可能失败的操作，用if err != nil处理；错误需用%w包装以保留原始错误链；自定义错误应嵌入底层error；禁用panic处理可预期错误。
用 if err != nil 检查每一个可能失败的操作
Go 不会自动跳过错误，也不会隐式抛出异常。你写的每一行可能返回 error 的调用，都得显式检查——这不是冗余，是责任边界。忽略它，等于把崩溃留给下游或用户。
- 常见错误现象：在
os.Open、json.Unmarshal、http.Do后没检查err，导致后续 panic 或静默失败 - 不要写
_, err := doSomething(); if err != nil { ... }，除非你真不需要返回值；否则容易漏掉关键数据 - 避免在循环里只打印日志却不返回或中断——比如批量处理文件时，一个失败不该让全部静默跳过
- 初始化阶段（如
main函数开头）可用log.Fatal，但服务运行中应返回错误并由上层决定重试、降级或返回 HTTP 500
用 %w 包装错误，别丢原始错误链
从 Go 1.13 起，fmt.Errorf("xxx: %w", err) 是加上下文的唯一推荐方式。它保留了原始错误的类型和值，让 errors.Is 和 errors.As 能正常工作。用 %v 或字符串拼接就等于自断诊断路径。
- 错误示例：
return errors.New("config load failed: " + err.Error())→ 原始os.ErrNotExist信息丢失，无法用errors.Is(err, os.ErrNotExist)判断 - 正确写法：
return fmt.Errorf("loading config: %w", err) - 包装层级不宜过深——3 层以内较合理；超过后调试成本陡增，不如重构逻辑或提前分类
-
errors.Unwrap只在必要时手动调用（比如日志脱敏），日常判断一律用errors.Is/errors.As
定义自定义错误类型时，优先实现 Error() 并嵌入原始 error
当需要区分业务错误（如参数校验失败、权限不足）或携带结构化字段（如 Field、Code）时，结构体错误比字符串更可靠。但别忘了把底层错误存进去，否则又断链了。
- 推荐结构：
type ValidationError struct { Field string; Msg string; Err error }，并在Error()方法里组合输出 - 这样既支持
errors.As(err, &e)提取字段，也能用errors.Unwrap(e)拿到原始错误 - 避免只存字符串：
Msg string而不存Err error，会导致无法追溯 I/O 或网络错误源头 - HTTP 服务中可据此映射状态码：
if errors.As(err, &validationErr) { http.Error(w, validationErr.Msg, http.StatusBadRequest) }
别用 panic 处理可预期错误
panic 是给不可恢复的编程错误用的，比如空指针解引用、数组越界、断言失败。把它当成“高级 return err”是最大误区——它破坏调用栈、难测试、掩盖真实错误类型。
立即学习“go语言免费学习笔记（深入）”；
- 典型滥用场景：数据库查询返回
sql.ErrNoRows时panic，而不是用errors.Is(err, sql.ErrNoRows)分支处理 -
recover只应在最外层入口（如 HTTP handler、goroutine 启动函数）做兜底，且必须配合日志记录原始 panic 值 - 单元测试中遇到
panic必须用defer recover()捕获，否则测试直接失败；而普通error可直接断言，简洁可靠 -
标准库几乎不用
panic处理业务错误——json.Unmarshal返回error，time.Parse返回error，这才是 Go 的一致性
最容易被忽略的一点：错误不是日志，也不是通知。它是一等公民返回值，要参与控制流、影响重试策略、决定 HTTP 状态码、甚至驱动熔断。写错一行 %w，可能让运维查三天日志都找不到原始磁盘满错误。
