Go中错误是显式返回的接口而非异常，需用error接口、%w包装、errors.Is/As判断，避免panic滥用、忽略Close错误及重复日志。
Go 中的错误不是异常，error 是一个接口
Go 不支持 try/catch，所有错误都通过返回 error 值显式传递。这意味着你不能“忽略”错误——编译器不会报错，但逻辑可能在静默中失败。error 接口只定义了一个方法：Error() string，所以任何实现了该方法的类型都可以作为错误返回。
常见误区是用 panic 处理本应返回 error 的场景（比如文件不存在、网络超时）。panic 应仅用于真正不可恢复的程序状态（如 nil 指针解引用、数组越界），而非业务错误。
- 函数签名中必须显式声明
error返回值，例如：func Open(name string) (*File, error) - 不要用
fmt.Errorf("something failed")丢掉原始错误上下文；优先用fmt.Errorf("wrap: %w", err)保留底层错误链 - 自定义错误类型应实现
Unwrap() error和Is(error) bool（如果需支持errors.Is或errors.As）
用 errors.Is 和 errors.As 替代字符串匹配
过去常有人写 if strings.Contains(err.Error(), "no such file") 来判断错误类型——这脆弱且易破。Go 1.13 引入了错误包装（%w）和标准判断工具，让错误处理可维护。
errors.Is(err, fs.ErrNotExist) 判断是否为某类预定义错误；errors.As(err, &pathErr) 尝试将错误解包并赋值给具体类型变量，比类型断言更安全（能穿透多层包装）。
立即学习“go语言免费学习笔记（深入）”；
- 只有用
%w包装的错误才可被errors.Is/errors.As正确识别 -
标准库中的 I/O 错误（如
os.PathError）、网络错误（如net.OpError）都支持这些操作 - 避免在中间层无意义地重 wrap：比如
return fmt.Errorf("read config: %w", err)合理，但return fmt.Errorf("failed: %w", err)无信息增量
不要在 defer 中直接调用带副作用的 Close() 而不检查错误
很多 Go 新手写 defer f.Close() 就以为万事大吉。但 Close() 可能返回非 nil 错误（尤其写入缓冲未刷盘、网络连接提前断开等），而 defer 中的错误会被丢弃。
正确做法是在函数末尾显式调用并检查，或使用辅助函数封装逻辑。对 io.ReadCloser / io.WriteCloser 等组合接口，也要注意 Close() 是否可能掩盖前序读写错误。
- 典型反模式：
defer f.Close()后无任何错误处理 - 推荐方式：用
if err := f.Close(); err != nil { /* handle */ }显式捕获 - 若需延迟关闭且关心错误，可定义局部变量保存：
var closeErr error; defer func() { if e := f.Close(); e != nil && closeErr == nil { closeErr = e } }()
日志与错误传播要分清：记录 ≠ 处理，返回 ≠ 忽略
看到错误就 log.Printf 一顿然后继续返回 nil，是高频陷阱。日志只是可观测性手段，不代表你已处理了错误；同样，把错误原样返回不是偷懒，而是职责分离——由调用方决定重试、降级还是告警。
关键原则：每个错误值应在**恰好一个地方**被“消费”——要么被修复（如重试、兜底值），要么被记录后转为用户可见提示，要么被包装后向上返回。重复记录或层层返回却不检查，会导致错误被淹没或报警泛滥。
- 避免：
log.Println(err); return err—— 日志和返回同时做，但上层可能又 log 又 return，造成重复输出 - 建议：内部函数只返回错误；最外层（如 HTTP handler、CLI main）统一记录 + 用户反馈
- 敏感信息（密码、token、完整路径）不要直接打到日志；可用
errors.Unwrap提取底层错误再脱敏
实际项目中最容易被忽略的是错误包装的深度和一致性：有些层用 %w，有些层用 %v，导致 errors.Is 失效；还有人在 HTTP handler 里把所有错误都 http.Error(w, "server error", 500)，彻底丢失错误分类能力。这些细节不难改，但需要从第一行错误返回就开始设计。
