Go错误处理优化核心是封装可复用、带语义、支持扩展的函数：WrapE自动注入位置与traceID；统一ErrorCode映射HTTP响应；DoWithRecover简化panic兜底；结构化日志联动链路追踪。
Go 语言的错误处理强调显式判断和传播，但重复写 if err != nil 容易让业务逻辑被噪声淹没。优化方向不是隐藏错误，而是减少样板代码、统一上下文、增强可追溯性——核心是封装可复用、带语义、支持扩展的错误处理函数。
封装带上下文的错误包装函数
原生 errors.Wrap 或 fmt.Errorf("%w", err) 只加一层信息。实际开发中常需自动注入函数名、行号、请求 ID、时间戳等。可封装一个轻量函数：
- 用
runtime.Caller(1)获取调用位置，提取文件名和行号 - 从 context 中提取 traceID（如使用
req.Context().Value("trace_id")） - 组合成结构化错误消息，再用
fmt.Errorf包装原错误
示例：
func WrapE(ctx context.
Context, err error, msg string) error {if err == nil { return nil }
_, file, line, _ := runtime.Caller(1)
traceID := ctx.Value("trace_id")
detail := fmt.Sprintf("[%s:%d][trace:%v] %s", filepath.Base(file), line, traceID, msg)
return fmt.Errorf("%s: %w", detail, err)
}
统一错误分类与响应转换
HTTP 接口返回错误时，不应直接暴露底层错误（如数据库超时、空指针），而应映射为预定义的业务错误码和用户友好提示。建议定义错误类型枚举（如 ErrInvalidParam, ErrNotFound），并封装转换函数：
- 每个业务错误实现
ErrorCode() int和ErrorMsg() string方法 - 中间件或 handler 中统一调用
RenderError(w, err)，自动识别错误类型并生成 JSON 响应 - 对非业务错误（如网络失败），默认转为 500 并记录日志，不暴露细节
用 defer + 自定义 panic 捕获简化临界路径
某些场景（如资源清理、事务回滚）需确保错误发生后执行收尾逻辑。与其在每个分支写 defer tx.Rollback()，不如封装一个“带恢复的执行器”：
- 定义
DoWithRecover(fn func() error) (err error) - 内部用
defer捕获 panic，并尝试转为特定错误（如ErrPanic{Recovered: v}） - 业务函数内可放心用
panic(errors.New("xxx"))表达不可恢复错误，由执行器统一兜底
注意：仅用于明确可控的 panic 场景，不替代正常错误返回。
错误日志与链路追踪联动
单靠打印 err.Error() 很难定位问题。优化做法是：在错误包装或处理入口处，主动将错误写入结构化日志，并注入 traceID、spanID、当前服务名：
- 用
log.With().Str("error", err.Error()).Str("trace_id", tid).Err(err).Send()（如使用 zerolog） - 若使用 OpenTelemetry，可在错误发生时调用
span.RecordError(err)，自动关联到当前 trace - 避免在多层重复记录同一错误，只在最外层（如 handler 或 middleware）做一次结构化记录
不复杂但容易忽略。关键是把错误当作可观测性的一环，而非仅用于控制流。
