Go错误处理强调显式返回error值而非异常，需通过自定义错误类型（含Unwrap方法）、errors.Is/As精准匹配、谨慎使用panic/recover及分层包装策略实现可控可追踪的健壮错误处理。
Go 语言的错误处理强调显式、可控和可追踪。它不依赖异常机制，而是通过返回 error 值让调用方决定如何响应。但面对复杂业务场景，仅靠 errors.New 或 fmt.Errorf 往往不够——你需要携带上下文、支持类型断言、能区分错误种类，甚至在某些不可恢复时主动中断并安全收尾。这正是自定义错误类型与 panic/recover 的用武之地。
定义可识别、可扩展的自定义错误类型
标准库的 error 接口只规定一个 Error() string 方法，但实际开发中常需更多能力：比如判断是否为超时、是否由数据库触发、是否可重试。这时应定义结构体错误类型，并实现 error 接口。
常见做法是嵌入字段（如时间、状态码、原始错误）并提供方法：
- 导出字段便于外部检查（如
err.Code），或用非导出字段 + 方法封装（更安全） - 实现
Unwrap() error支持errors.Is和errors.As（Go 1.13+） - 重写
Error()返回可读信息，同时保留结构化数据
示例：
立即学习“go语言免费学习笔记（深入）”；
type DatabaseError struct {
Query string
Code int
Err error
}
func (e *DatabaseError) Error() string {
return fmt.Sprintf("database error[code=%d] on query %q: %v", e.Code, e.Query, e.Err)
}
func (e *DatabaseError) Unwrap() error { return e.Err }
// 使用
if errors.As(err, &dbErr) {
log.Printf("DB error code: %d", dbErr.Code)
}用 errors.Is 和 errors.As 精准匹配错误语义
避免用字符串比较（strings.Contains(err.Error(), "timeout")）或指针相等（err == io.EOF），它们脆弱且无法穿透包装错误。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
errors.Is 递归检查错误链中是否存在某个目标错误（适合判断是否为某类错误，如超时、取消）；errors.As 尝试将错误链中第一个匹配类型的错误提取出来（适合获取自定义错误实例）。
-
errors.Is(err, context.DeadlineExceeded)—— 判断是否超时 -
errors.Is(err, sql.ErrNoRows)—— 判断是否查无结果 -
errors.As(err, &myErr)—— 提取你的*MyCustomError
前提是你的自定义错误实现了 Unwrap()，或使用 fmt.Errorf("%w", underlying) 包装底层错误。
谨慎使用 panic/recover：只用于真正不可恢复的程序错误
panic 不是错误处理手段，而是终止当前 goroutine 并触发栈展开的信号。Go 官方明确建议：仅在遇到**本不该发生、无法继续执行**的情况时使用，例如空指针解引用、合约违反（invariant violation）、初始化失败等。
- 不要用
panic替代return err，尤其在公开 API 或库函数中 -
recover只在defer函数中有效，且仅能捕获当前 goroutine 的 panic - 典型安全用法：HTTP 服务器的顶层 handler 中
defer func(){ if r := recover(); r != nil { log.Panic(r) } }()，防止 panic 导致整个服务崩溃
注意：recover 不能跨 goroutine 捕获 panic。若在 goroutine 内 panic，必须在该 goroutine 内 defer recover，否则会直接终止进程。
组合策略：包装 + 类型断言 + 顶层恢复
生产级错误处理往往是分层的：
- 底层函数返回具体错误（如
&ValidationError{Field: "email"}） - 中间层用
%w包装并添加上下文（fmt.Errorf("failed to create user: %w", err)） - 业务逻辑用
errors.As分流处理（验证失败则返回 400，DB 错误则重试或告警） - 最外层（如 HTTP handler、CLI main）用
defer/recover拦截意外 panic，记录堆栈并返回 500
这种组合兼顾了可调试性、可维护性和健壮性——错误携带足够信息，分类清晰，失控时仍有兜底。
