17370845950

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 判断类型、提取底层原因。

常见错误模式：

• ❌ 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 要贯穿。坚持下来，排障效率会明显提升。