Go错误处理应统一分类、封装构造与判断、注入上下文、分层处理；用语义化错误类型替代字符串比较，通过%w构建错误链，errors.Join合并多错，中间件/defer外提错误处理，结构化日志注入上下文。
Go 语言中错误处理本就强调显式、直接，但若不加设计，容易在各处重复写 if err != nil + 日志/返回/包装逻辑，导致代码冗长、职责不清、错误上下文丢失。优化核心是：统一错误分类、封装错误构造与判断、按需注入上下文、分层处理（不全在业务函数里 panic 或 return），而非消灭 if 判断。
定义语义化错误类型，替代字符串比较
避免用 errors.New("user not found") 或 err.Error() == "xxx" 做判断——脆弱且无法携带结构化信息。应定义可识别的错误变量或自定义类型：
- 对固定业务错误，用全局变量：var ErrUserNotFound = errors.New("user not found")
- 需携带字段（如 ID、code）时，实现
error接口并支持Is/As：
type NotFoundError struct { Resource string; ID int }
func (e *NotFoundError) Error() string { return fmt.Sprintf("%s %d not found", e.Resource, e.ID) }
func (e *NotFoundError) Is(target error) bool { _, ok := target.(*NotFoundError); return ok }
调用方即可用 errors.Is(err, ErrUserNotFound) 或 errors.As(err, &e) 安全判断，不依赖字符串匹配。
立即学习“go语言免费学习笔记（深入）”；
使用 errors.Join 和 errors.Unwrap 构建错误链
下层出错时，不要丢弃原始错误。用 fmt.Errorf("failed to save order: %w", err)（%w）保留底层错误链；上层可逐层 errors.Unwrap 检查根本原因，或用 errors.Is 跨层级判断语义错误。
多个错误同时发生？用 errors.Join(err1, err2, err3) 合并，避免只上报第一个而遗漏关键失败点。HTTP handler 中可统一将 Join 后的错误转为 500 并记录所有子错误。
中间件/defer 统一捕获与转换（尤其 HTTP 层）
业务 handler 内不应每步都写日志+return。可借助中间件或 defer 将错误处理“外提”：
- HTTP handler 包一层
func(w http.ResponseWriter, r *http.Request) { if err := realHandler(w, r); err != nil { writeErrorResponse(w, err) } } - 数据库操作等可封装为带 recover 的 wrapper，将 panic（如空指针）转为特定错误（
ErrInternal），再由上层统一处理
这样业务逻辑专注“做什么”，不掺杂“怎么报错”。
错误日志分级 + 上下文注入（不用拼接字符串）
避免 log.Printf("failed to parse json for user %d: %v", userID, err)。改用结构化日志库（如 zap）+ fmt.Errorf("parse request body: %w", err)，并在入口处（如 handler）用 logger.With(zap.Int64("user_id", userID)) 注入上下文。错误链保持完整，日志字段自动携带，排查时无需翻源码找参数来源。
