Go 错误是需显式检查的接口，非异常；必须调用后立即检查 err != nil 并处理，不可忽略；优先用 fmt.Errorf("%w") 包装错误以支持类型识别，仅对真正不可恢复状态用 panic。
Go 的错误不是异常，error 是一个接口，必须显式检查、显式传递——不处理就留着，不会自动中断或跳转。
为什么 if err != nil 出现在每行函数调用后？
因为 Go 没有 try/catch，也不隐式传播错误。函数返回 error 类型值，调用方有责任判断是否出错，并决定是返回、重试、记录还是 panic。
- 这不是啰嗦，是可控性设计：每个错误分支都清晰可见，无法被忽略（静态分析工具如
errcheck可捕获未检查的error） - 常见误写：
_, err := os.Open("x"); doSomething(); if err != nil { ... }—— 错在doSomething()在检查前执行，可能依赖打开失败的文件句柄 - 正确顺序永远是：调用 → 立即检查 → 分支处理（或提前 return）
errors.New 和 fmt.Errorf 该怎么选？
errors.New 仅构造带固定字符串的简单错误；fmt.Errorf 支持格式化、嵌套（用 %w）和上下文注入。
- 日志或调试需要更多信息时，优先用
fmt.Errorf("failed to parse %s: %w", filename, err) -
%w是关键：它让errors.Is和errors.As能穿透包装链识别原始错误类型 - 避免
fmt.Errorf("something went wrong: %v", err)—— 这会丢失原始错误类型，且无法用%w解包
什么时候该用 panic？
仅限程序无法继续运行的**真正异常状态**，比如初始化失败、空指针解引用、不可恢复的配置错误——不是业务错误的替代品。
立即学习“go语言免费学习笔记（深入）”；
- HTTP handler 中
panic会导致整个 goroutine 崩溃，除非用recover捕获（但应由框架统一处理，业务逻辑里别自己 recover） - 库函数中慎用
panic：调用方无法预期，破坏接口契约；改用返回error更安全 -
json.Unmarshal返回error而非 panic，就是典型范例：输入非法是常见场景，不是“异常”
自定义错误类型要实现什么？
如果需要区分错误种类（比如网络超时 vs 连接拒绝）、携带额外字段（如重试次数、请求 ID），就该定义结构体并实现 Error() string 方法。
- 同时实现
Unwrap() error才能支持%w包装和errors.Unwrap - 若需类型断言，导出错误类型（首字母大写），例如：
type TimeoutError struct{ ... }，再用errors.As(err, &e)提取 - 不要只为加字段而造类型：多数场景
fmt.Errorf+%w已足够；定制类型意味着维护成本和调用方认知负担
最易被忽略的一点：错误不是装饰品。传出去的 error 值，要么被上层处理，要么被日志记录，否则就是静默失败。Go 不强制你写 if err != nil，但它强制你面对每一个错误的存在。
