Go 错误处理通过显式返回 error 接口值实现，必须检查；error 是接口，常用 errors.New 和 fmt.Errorf（推荐 %w 包装）；函数需返回 (T, error) 并处理；用 errors.Is/As 判断类型；error 表示预期失败，panic 表示严重异常。
Go 语言的错误处理不靠 try/catch，而是明确返回 error 类型值——这意味着你必须显式检查、传递或处理它，否则就是潜在 bug。
error 是接口，不是类型
Go 的 error 是一个内置接口：
type error interface {
Error() string
}
任何实现了 Error() 方法的类型，都可赋值给 error。标准库里最常用的是 errors.New() 和 fmt.Errorf()，它们返回的都是满足该接口的私有结构体。
-
errors.New("msg")：适合简单、无格式化的错误描述 -
fmt.Errorf("failed to %s: %w", op, err)：推荐用于包装错误（带%w），保留原始错误链 - 不要用
fmt.Sprintf或字符串拼接替代fmt.Errorf，否则丢失错误嵌套能力
函数必须显式返回 error 并检查
Go 中没有“未声明即忽略”的错误机制。典型模式是函数返回 (T, error)，调用方必须处理第二个返回值：
data, err := ioutil.ReadFile("config.json")
if err != nil {
log.Fatal(err) // 或 return err，或做其他处理
}
// 此时 data 才可信
- 不能只写
if err != nil就跳过后续逻辑，还要确保变量在错误路径下不被误用 - 避免
if err != nil { return nil, err }后还继续写业务代码（常见低级错误） - 短变量声明
:=在多返回值中容易掩盖已有变量，建议先声明再赋值，或统一用if err := f(); err != nil形式
判断错误类型要用 errors.Is() 和 errors.As()
别用 == 或 strings.Contains(err.Error(), "...") 判断错误种类——这脆弱且无法处理包装后的错误。
-
errors.Is(err, fs.ErrNotExist)：判断是否为某个已知错误（支持嵌套） -
errors.As(err, &pathErr)：尝试把错误转成具体类型（如*os.PathError），用于提取字段 - 自定义错误应实现
Unwrap() error方法才能被errors.Is/As正确识别
error 不是 panic，不要混用
panic 表示程序无法继续的严重异常（如空指针解引用、切片越界），而 error 是预期中的失败结果（如文件不存在、网络超时）。两者语义完全不同：
立即学习“go语言免费学习笔记（深入）”；
- HTTP handler 中遇到
os.Open失败，应返回500 Internal Server Error+ 日志，而不是panic -
recover只应在极少数顶层入口（如 HTTP 中间件）捕获意外 panic，绝不能用来替代错误检查 - 标准库几乎从不在公开 API 中 panic，除非你传了明显非法参数（如
regexp.Compile("")）
最容易被忽略的一点：很多人把 error 当作“可选副产物”，实际它是 Go 接口契约的一部分——不检查，就等于放弃对控制流的掌控。