go 错误处理核心是将 error 视为值而非异常，需通过自定义类型（如 usernotfounderror）、%w 包装、apperror 统一转换，在 service 层完成语义识别与分类，避免中间层字符串拼接或 defer 覆盖，确保错误可判断、可响应、可监控。
Go 语言中业务逻辑错误不是要“掩盖”或“忽略”，而是要明确区分错误类型、传递上下文、并在合适层级处理——error 是值，不是异常，不能靠 recover 拦截。
用自定义 error 包装业务语义，别只用 errors.New 或 fmt.Errorf
裸字符串错误（如 fmt.Errorf("user not found")）无法在调用方做类型判断，也丢失了结构化信息。业务系统需要能识别“用户不存在”“余额不足”“并发冲突”等语义，并分别响应。
- 定义带方法的 error 类型，例如
type UserNotFoundError struct{ UserID int }，实现Error()方法 - 配合
errors.Is和errors.As做语义判断：if errors.As(err, &UserNotFoundError{}) { ... } - 避免在中间层把 error 转成字符串再拼接，会破坏类型信息；要用
fmt.Errorf("failed to update order: %w", err)保留原始 error 链
在 service 层统一做错误分类与转换，不要让 handler 直接处理底层 error
数据库错误（如 pgconn.PgError）、RPC 错误、校验错误混在一起传到 HTTP handler，会导致响应码混乱、日志难排查。
- service 方法返回标准业务 error，例如
*AppError，内含Code（如"USER_NOT_FOUND"）、HTTPStatus、Message（用户可见）和DebugMsg（仅日志） - DAO 层错误应在 service 中被翻译：
if pgErr.Code == "23505" { return &AppError{Code: "DUPLICATE_EMAIL", HTTPStatus: http.StatusConflict} } - handler 只需根据
AppError.Code决定状态码和 JSON 字段，不感知 PostgreSQL 或 Redis 细节
避免在 defer 中覆盖主函数返回的 error
常见反模式：主逻辑返回了 err，但 defer 里的 Close() 也出错，且直接赋值给同名 err 变量，导致原始业务错误丢失。
立即学习“go语言免费学习笔记（深入）”；
- 显式声明命名返回值（
func DoSomething() (result string, err error)），并在defer中用if closeErr := f.Close(); closeErr != nil && err == nil判断是否覆盖 - 更稳妥的做法是：对必须关闭的资源，用
io.Closer+ 单独 error 日志，不干扰主流程错误；例如log.Printf("close file failed: %v", f.Close()) - 使用
defer func() { if r := recover(); r != nil { ... } }()仅用于捕获 panic，绝不用于“兜底错误”——这违背 Go 的错误处理哲学
真正难的不是写 if err != nil，而是决定在哪一层把一个底层存储错误，翻译成用户能理解、前端能提示、监控能告警的业务信号。这个决策点一旦模糊，错误就会在各层之间“漂移”，最后只能靠日志关键词硬搜。
