go错误处理核心是显式检查每个err、用%w包装、用errors.is/as判断；跳过检查易致panic，错误链断裂则无法精准诊断，自定义错误需嵌入err字段以支持标准工具链。
Go 的错误处理没有“最佳实践”清单，只有“不踩坑”的共识：每个 err 都得显式检查，每个包装都得用 %w，每个判断都得靠 errors.Is 或 errors.As——不是为了炫技，是为了一旦出错，你能立刻知道“谁干的、在哪干的、能不能救”。
为什么不能跳过 if err != nil
Go 不会替你跳过失败逻辑，也不会隐式中断执行。写 json.Unmarshal(data, &v) 却不检查 err，后续访问 v 很可能 panic；写 os.Open("config.yaml") 忽略错误，程序就带着空指针一路跑进生产环境。
- 常见错误现象：用
_, err := doSomething()丢掉返回值，只留err——结果关键数据丢了，错误还查不出上下文 - 初始化阶段（如
main开头）可用log.Fatal，但服务运行中必须返回error，由上层决定重试、降级或返回 HTTP 状态码 - 循环里只
log.Printf却不return或break，比如批量读文件时一个失败，其余全被静默跳过
fmt.Errorf 里的 %w 到底怎么用
不用 %w，等于主动切断错误链。用 fmt.Errorf("loading config: %v", err) 或拼接字符串，原始错误类型（比如 os.ErrNotExist）就没了，errors.Is(err, os.ErrNotExist) 永远返回 false。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确写法：
return fmt.Errorf("loading config: %w", err)——保留底层错误的所有能力 - 包装层级不宜过深：同一错误被
%w包装超过 3 层，调试时容易迷失；优先在模块边界（如函数出口、HTTP handler 入口）包装一次，补充语义即可 - 别滥用堆栈：中间层包装不必加堆栈；需要堆栈线索时，只在最外层用第三方库（如
github.com/pkg/errors）或 Go 1.22+ 的errors.AddStack
什么时候该定义自定义错误类型
当错误需要携带结构化字段（比如 Code、Field、Retryable），或者要被其他模块精确识别并分支处理时，就不能只靠 fmt.Errorf 返回字符串了。
- 推荐结构：
type ValidationError struct { Field string; Code string; Err error }，并在Error()方法里组合输出 - 必须嵌入
Err error字段：否则errors.As提取不到原始 I/O 错误，errors.Is也判不了os.ErrNotExist - HTTP 服务中可据此映射状态码：
if errors.As(err, &validationErr) { http.Error(w, validationErr.Msg, http.StatusBadRequest) } - 避免只存字符串：
Msg string而不存Err error，等于把诊断线索全删了
errors.Is 和 errors.As 为什么不能用字符串匹配代替
用 strings.Contains(err.Error(), "timeout") 判断超时，既脆弱又难维护：日志格式一变就失效，多层包装后内容被截断，甚至不同错误碰巧含相同关键词也会误判。
-
errors.Is(err, os.ErrNotExist)可穿透任意层%w包装，稳定可靠 -
errors.As(err, &pathErr)能提取底层*os.PathError的Path和Op字段，比解析字符串强十倍 - 标准库错误（如
sql.ErrNoRows、os.ErrPermission）已原生支持errors.Is，无需额外适配 - 自定义错误若需支持
Temporary()等方法，应显式实现，而不是靠字符串猜
最常被忽略的一点是：错误包装不是为了记录调用栈，而是回答“这个错误对当前层级意味着什么”。多包一层没意义，少包一层就断链——分寸感比语法更重要。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
