Go错误治理核心是结构化包装与分类：用%w保留上下文，自定义AppError携带码/状态/重试等元信息，分层添加业务上下文，配合errors.Is/As实现类型安全处理，使错误可查、可溯、可响应。
Go 语言中错误过多、堆叠混乱、难以定位根本原因，本质不是“错得太多”，而是错误没被有结构地组织和传递。优化核心是：用错误包装（fmt.Errorf + %w）保留原始上下文，再通过自定义错误结构体统一分类、携带元信息（如错误码、请求ID、重试建议），让错误可查、可溯、可响应。
用 %w 正确包装错误，避免丢失根因
直接返回底层错误（如 return err）或用 + " failed" 拼接，都会切断错误链。必须用 %w 显式包装，才能被 errors.Is / errors.As 向下匹配：
- ✅ 正确：
return fmt.Errorf("failed to parse config: %w", err) - ❌ 错误：
return errors.New("failed to parse config: " + err.Error())（丢失原始 error 类型与堆栈） - ⚠️ 注意：
%w只接受一个 error 类型参数，不支持多个；若需多错误聚合，用第三方库如pkg/errors或 Go 1.20+ 的errors.Join
定义业务错误结构体，分离语义与处理逻辑
把错误从字符串升级为结构体，能自然承载错误码、HTTP 状态、是否可重试等字段，让 handler 层按类型决策，而不是靠字符串 contains 判断：
type AppError struct {
Code string `json:"code"` // 如 "ERR_CONFIG_INVALID"
Message string `json:"message"`
Status int `json:"status"` // HTTP 状态码
Retry bool `json:"retry"` // 是否建议客户端重试
ReqID string `json:"req_id,omitempty"
}
func (e *AppError) Error() string { return e.Message }
func (e *AppError) Is(target error) bool {
t, ok := target.(*AppError)
if !ok { return false }
return e.Code == t.Code
}
- 在关键入口（如 HTTP handler）统一 recover & 转换：遇到
*AppError直接取Status和Code返回；遇到未包装的 panic 或底层 error，兜底转为InternalError - 日志中间件可自动提取
ReqID和Code，便于 ELK 关联追踪
分层封装错误，每层只加必要上下文
错误传递应像洋葱：外层只关心“哪一步失败了”，内层保留“为什么失败”。避免在 DAO 层就写 “failed to insert user” —— 这是 service 层该描述的：
立即学习“go语言免费学习笔记（深入）”；
- DAO 层：
return fmt.Errorf("db exec failed: %w", err)（只加技术动作） - Service 层：
return fmt.Errorf("create user %s failed: %w", email, err)（加业务标识） - Handler 层：
return &AppError{Code: "ERR_USER_CREATE", Message: "注册用户失败", Status: http.StatusInternalServerError}（加响应策略）
这样调用 errors.Unwrap(err) 可逐层退到最原始错误，errors.Is(err, sql.ErrNoRows) 也能精准判断底层 DB 状态。
配合 errors.As 提取并分类处理特定错误
结构体化之后，就能在上层做类型安全的错误分流，而不是用字符串匹配或 switch err.Error()：
- 检测是否是数据库唯一约束冲突：
var pqErr *pq.Error; if errors.As(err, &pqErr) && pqErr.Code == "23505" { ... } - 检测是否是自定义超时错误：
var timeoutErr *TimeoutError; if errors.As(err, &timeoutErr) { log.Warn("slow call", "duration", timeoutErr.Duration) } - 检测是否是业务拒绝错误（如余额不足）：
if errors.Is(err, ErrInsufficientBalance) { return &AppError{Code: "BALANCE_LOW", Status: http.StatusBadRequest} }
所有分支都基于类型或预设变量，稳定、可测试、易维护。
基本上就这些。错误不是要消灭，而是要驯服——包装留痕、结构赋义、分层加料、类型识别。做得好，报错日志能直接当排查文档用。
