Go错误处理靠显式检查error值，强制每步明确失败可能性及应对策略；if err != nil非冗余而是必要习惯，panic仅用于不可恢复的致命错误。
Go 的错误处理不是靠 try/catch，而是靠显式检查 error 值——这本身不“优雅”，但能让你一眼看清哪里可能出错、必须怎么应对。
为什么 if err != nil 不是代码坏味道
很多人初学 Go 时反感满屏的 if err != nil，觉得冗长。其实这是 Go 强制你做两件事：明确知道哪一行可能失败，以及立刻决定失败后怎么处理（返回、重试、记录、包装）。跳过它，等于默认忽略错误路径，后端服务就容易在异常输入或网络抖动时静默失败或 panic。
实操建议：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 不要用
err := doSomething()后直接继续写逻辑；始终紧跟着if err != nil分支 - 避免把多个操作链在一行里（如
a, b, err := f(), g(), h()），这样无法定位具体哪个调用出错 - 如果某步错误可忽略（比如日志写入失败），也得显式写成
_ = log.Write(...)，而不是删掉检查
errors.Is 和 errors.As 怎么用才不踩坑
Go 1.13 引入的这两个函数，是用来应对「错误包装」场景的。比如 fmt.Errorf("read failed: %w", io.EOF) 包装了原始错误，此时直接用 err == io.EOF 会失效。
立即学习“go语言免费学习笔记（深入）”；
常见错误现象：HTTP handler 中判断是否为 context.Canceled，却用 err == context.Canceled 导致超时请求没被正确识别，连接堆积。
实操建议：
- 判类型用
errors.As(err, &target)（target是对应错误类型的指针） - 判相等用
errors.Is(err, io.EOF)或自定义哨兵错误（如var ErrNotFound = errors.New("not found")） - 不要对第三方库返回的错误做字符串匹配（如
strings.Contains(err.Error(), "timeout")），不稳定且易破
什么时候该用 panic，什么时候绝不能用
panic 在 Go 里只适用于「程序无法继续运行」的致命缺陷，比如配置加载失败、数据库连接参数为空、依赖的全局变量未初始化。它不是错误处理机制，而是终止信号。
典型误用场景：
- HTTP handler 里对用户传入的 JSON 解析失败调
panic→ 整个 goroutine 崩溃，可能拖垮服务 - 数据库查询返回
sql.ErrNoRows就panic→ 这是业务常态，应该用if errors.Is(err, sql.ErrNoRows)处理 - 在 defer 中 recover 却不打印堆栈 → 错误被吞掉，问题难以复现
真正该用 panic 的地方极少，基本只出现在 init()、main() 开头校验，或封装底层不可恢复状态时（如 unsafe 操作前断言）。
如何让错误带上上下文又不破坏语义
裸错误（如 os.Open 返回的 "no such file or directory"）缺乏调用链信息，线上排查困难。但随便用 fmt.Errorf("failed to load config: %v", err) 又会让下游无法用 errors.Is 判断原始错误类型。
实操建议：
- 用
%w动词包装：fmt.Errorf("loading config from %s: %w", path, err) - 避免多层重复包装（如
fmt.Errorf("handler: %w", fmt.Errorf("service: %w", err))），会模糊原始错误来源 - 需要额外字段（如 traceID、userID）时，定义结构体实现
error接口，并在Error()方法里拼接，同时保留Unwrap()返回底层 error
最常被忽略的是：日志记录错误时，别只打 err.Error()。用 fmt.Printf("%+v", err)（配合 github.com/pkg/errors 或 Go 1.17+ 的内置支持）才能看到完整的调用栈和包装链。
