go语言错误处理强调清晰、可追踪、可恢复：立即检查if err != nil，优先清理后返回；用%w包装保留错误链，避免无意义包装；自定义错误类型需实现unwrap和error；用户侧应分层响应而非透出底层错误。
Go 语言里没有异常机制，error 是一等公民，所谓“优雅”不是避免错误，而是让错误流清晰、可追踪、可恢复。
用 if err != nil 立即检查，别攒着一起处理
Go 的错误处理不是 try/catch，延迟检查或集中处理会让调用栈丢失、上下文模糊。常见错误是把多个函数调用堆在一行后统一判错，比如：
err := doA(); doB(); doC() // 错！err 只反映 doA 的结果
正确做法是每个可能出错的调用后立刻检查：
-
if err != nil后优先做清理（如关闭文件、回滚事务），再返回或重包装 - 不要用
if err == nil { ... }包裹主逻辑——嵌套深、可读差、容易漏 return - 若连续调用都依赖前一步成功（如打开文件 → 读取 → 解析），就逐层返回，让错误自然向上传播
用 fmt.Errorf 或 errors.Join 包装错误，保留原始链路
直接返回底层错误（如 os.Open 返回的 *os.PathError）会丢失业务语义；但用 fmt.Errorf("xxx: %w", err) 的 %w 动词就能保留原始错误链，支持 errors.Is 和 errors.As 判断。
立即学习“go语言免费学习笔记（深入）”；
- 只在需要添加上下文时包装：比如 “failed to load config from
config.yaml: %w” - 避免无意义包装：如
fmt.Errorf("error occurred: %w", err)—— 没提供新信息 - 多个错误需合并时（如批量操作失败），用
errors.Join(err1, err2, ...)，它支持后续遍历和匹配
定义自定义错误类型时，优先实现 Unwrap 和 Error，慎用结构体字段暴露
如果需要区分错误种类（如验证失败 vs 网络超时），定义带方法的错误类型比纯字符串判断更可靠：
type ValidationError struct {
Field string
Value interface{}
}
func (e *ValidationError) Error() string {
return fmt.Sprintf("validation failed on field %q", e.Field)
}
func (e *ValidationError) Unwrap() error { return nil } // 不包裹其他错误时返回 nil
关键点：
- 实现
Unwrap()才能让%w包装生效、支持错误链解析 - 避免把错误细节（如原始 SQL、用户输入）直接塞进导出字段——可能泄露敏感信息或破坏封装
- 如需提取上下文，提供访问方法（如
Field()），而非暴露字段
在 HTTP handler 或 CLI 命令中，错误要分层响应，别把底层错误直接透出
终端用户看到 "no such file or directory" 并不比看到 "config not found" 更有用，反而暴露实现细节。
- HTTP handler 中：用
errors.Is(err, fs.ErrNotExist)判断后转成 404；用errors.As(err, &ValidationError{})提取后返回 400 + 结构化详情 - CLI 工具中：对
os.IsPermission(err)返回 “permission denied”，而不是原始系统错误消息 - 日志记录时才用
fmt%+v打印完整错误链，面向用户的输出要简洁、准确、有指导性
最常被忽略的是错误链的维护成本：每次包装都要想清楚“这个上下文是否真有助于诊断或恢复”。过度包装和完全不包装一样危险——前者掩盖关键路径，后者切断归因线索。
