Go 错误处理要求显式检查、返回和传递 error 接口，因错误是返回值而非异常；if err != nil 需紧跟调用以避免变量覆盖或状态错乱；errors.New 适用于静态错误，fmt.Errorf 支持动态格式化与错误嵌套（%w）；判断特定错误应使用 os.IsNotExist 等标准函数而非相等比较或字符串匹配；panic 仅用于不可恢复的编程错误，常规失败须返回 error。
Go 语言里没有异常（exception），error 是一个接口类型，必须显式检查、显式返回、显式传递——不处理就留着，程序不会自动中断或 panic。
为什么 if err != nil 几乎总得写在调用后一行
因为 Go 的错误不是“抛出”而是“返回”，绝大多数标准库和主流包都把 error 作为最后一个返回值。不立刻检查，err 变量可能被后续语句覆盖，或者逻辑继续执行导致状态错乱。
- 常见错误：调用
os.Open后没检查err，直接对返回的*os.File调用Read，结果 panic：nil pointer dereference - 正确姿势：哪怕只是提前 return，也要紧挨着调用写
if err != nil { return err } - 如果需要清理资源（比如已打开的文件），用
defer配合条件判断，或把逻辑包进作用域（如if f, err := os.Open(...); err != nil { ... }）
errors.New 和 fmt.Errorf 用哪个
两者都创建 *errors.errorString，但适用场景不同。
-
errors.New("failed to connect")：适合固定、无上下文的简单错误，性能略高，不可格式化 -
fmt.Errorf("connect to %s: %w", addr, err)：需要拼接动态值，或要嵌套原始错误（用%w）时必须用它；注意%w是 Go 1.13+ 引入的，用于支持errors.Is/errors.As - 别用
fmt.Errorf("... %s", err.Error())：丢掉了错误链，无法用errors.Unwrap追溯
怎么判断是不是某个特定错误（比如 os.IsNotExist）
不要用 err == fs.ErrNotExist 或字符串匹配——底层错误可能被包装过。
立即学习“go语言免费学习笔记（深入）”；
- 用标准判定函数最安全：
os.IsNotExist(err)、os.IsPermission(err)等，它们内部调用了errors.Is - 自定义错误需实现
Unwrap() error方法才能被errors.Is正确识别 - 若需提取具体错误类型（比如获取
*os.PathError），用errors.As(err, &pathErr)，不是类型断言
什么时候该用 panic，什么时候该返回 error
panic 不是错误处理机制，而是终止当前 goroutine 的信号。它只该用于“绝不该发生”的情况。
- 返回
error：I/O 失败、参数校验不通过、网络超时、配置缺失……所有预期中可能发生的失败 - 用
panic：初始化阶段发现无法修复的约束（如全局配置解析失败且无默认值）、空指针解引用前的防御性检查、不满足程序基本假设（如 switch 缺少 default 且枚举值已穷尽） - HTTP handler 里不要
panic，应该 recover 并转为 500 响应；但init()中的 panic 会直接终止进程，慎用
真正难的不是写 if err != nil，而是在多层调用中保持错误语义清晰、不丢失原始上下文、又不让日志堆满重复信息。包装错误时加关键现场信息（如操作对象、重试次数），比堆栈更管用。
