Go错误处理需包装原始错误并带上下文，用结构化日志库记录，按语义分级别输出，且全程贯穿traceID以实现可追踪。
日志要带上下文，错误要留痕迹
Go 的 log 包本身不支持结构化或字段化输出，直接用 log.Printf 打印错误容易丢失调用链和关键变量。推荐用 fmt.Errorf 套一层带上下文的错误，再配合结构化日志库（如 zap 或 zerolog）记录。
例如：
- 不要只写
log.Printf("failed to open file") - 而应：
err := fmt.Errorf("open config file %q: %w", filename, os.ErrNotExist)，再用logger.Error("file operation failed", zap.String("path", filename), zap.Error(err))
错误要包装，不要吞掉原始错误
Go 推崇“错误即值”，用 %w 动词包装错误可保留原始错误链，方便后续用 errors.Is 或 errors.As 判断类型、提取底层原因。
常见错误模式：
立即学习“go语言免费学习笔记（深入）”；
- ❌
return errors.New("database query failed")—— 丢掉了 SQL 错误细节 - ✅
return fmt.Errorf("query user by id %d: %w", id, err)—— 可追溯、可判断、可展开 - 在 HTTP handler 中，可统一用
if errors.Is(err, sql.ErrNoRows) { ... }做业务分流
日志级别要匹配错误语义
不是所有错误都该打 Error 级别。区分场景选级别，避免日志爆炸或关键问题被淹没：
- Debug：内部状态、重试前的中间错误（如网络超时但已自动重试）
- Warn：预期外但可恢复的情况（如缓存未命中、降级响应）
- Error：影响当前请求或流程的失败（如 DB 连接中断、JSON 解析失败）
-
Fatal：进程无法继续（如配置加载失败、监听端口被占用）——慎用，通常只在
main初始化阶段
加 traceID 实现错误可追踪
微服务或并发请求中，单靠时间戳和日志行很难串起一次完整调用。建议在入口（如 HTTP middleware）生成唯一 traceID，透传到下游日志与错误中。
简单做法：
- 用
context.WithValue(ctx, keyTraceID, id)注入上下文 - 所有日志调用都带上
zap.String("trace_id", getTraceID(ctx)) - 错误包装时也把 traceID 带上：
fmt.Errorf("trace_id=%s: write to kafka failed: %w", id, err) - 这样查一条报错，就能关联出整条链路的日志，定位快得多
基本上就这些。不复杂但容易忽略：错误要包装、日志要带上下文、级别要分清、traceID 要贯穿。坚持下来，排障效率会明显提升。
