Go标准log包不支持错误日志分级，因log.Fatal会退出进程、无级别标识、无法分流；推荐用Zap实现七级结构化日志，并依影响面与可恢复性动态定级。
Go 本身没有内置的错误日志分级机制（比如 log.Error / log.Warn），log 包只提供 log.Print、log.Fatal 等基础方法，且不区分错误严重性。要实现真正的错误日志分级，必须借助第三方日志库或自行封装。
为什么标准 log 包不能满足错误分级需求
标准 log 包的 log.Fatal 会直接调用 os.Exit(1)，无法用于记录“可恢复但需告警”的错误；log.Println 没有级别标识，无法在日志采集端（如 Loki、ELK）做 level 过滤；所有输出都走同一 writer，无法按级别分流到不同文件或通道。
-
log.Printf("failed to connect: %v", err)—— 无法被识别为 error 级别 - 没有结构化字段（如
"level": "error"），下游系统难以解析 - 不支持上下文（
context.Context）透传，丢失 traceID、requestID 等关键追踪信息
推荐用 zap 实现结构化错误分级日志
zap 是目前 Go 生态最主流的高性能结构化日志库，原生支持 Debug、Info、Warn、Error、Dpanic、Panic、Fatal 七级，并能将错误对象自动展开为字段（如 err="timeout: context deadline exceeded"）。
关键实操点：
立即学习“go语言免费学习笔记（深入）”；
- 使用
zap.Error(err)而非zap.String("err", err.Error())，前者会保留错误类型、堆栈（若启用Stacktrace） - 对 recover 的 panic，用
logger.Fatal("panic recovered", zap.String("stack", string(debug.Stack()))) - HTTP handler 中建议统一包装：遇到业务错误用
logger.Warn("user not found", zap.String("user_id", uid))，底层依赖失败用logger.Error("db query failed", zap.Error(err))
logger, _ := zap.NewProduction()
defer logger.Sync()
if err := doSomething(); err != nil {
logger.Error("failed to process item",
zap.String("item_id", "123"),
zap.Error(err), // 自动提取 error 类型、消息、栈（若配置）
zap.Duration("elapsed", time.Since(start)),
)
}
自定义 error 日志 wrapper 的常见陷阱
有人倾向封装一个 LogError(err error, msg string, fields ...any) 来统一处理，但容易忽略三点：
- 错误是否已打印过？重复记录
io.EOF这类高频非致命错误会造成日志爆炸 - 是否混淆了「错误发生」和「错误处理」：比如
os.Open失败是 error 级，但上层用默认值 fallback 后，应记为Warn而非Error - 是否把
fmt.Errorf("wrap: %w", err)的原始错误丢弃？要用errors.Is或errors.As判断根因，再决定日志级别
例如：if errors.Is(err, context.DeadlineExceeded) { logger.Warn("request timeout", zap.Error(err)) }，而不是一概 Error。
生产环境错误日志分级的实际分界线
不是所有 err != nil 都该记为 Error。更合理的分法取决于影响面和可恢复性：
-
Fatal：进程无法继续（如监听端口失败、配置加载失败） -
Error：外部依赖不可用（DB 连接断、下游 HTTP 503）、数据损坏、权限拒绝 -
Warn：预期外但可降级（缓存未命中、重试后成功、用户传了废弃参数） -
Info：关键业务状态（订单创建成功、支付回调接收）—— 不是“无错误才 Info”
真正难的是动态判断：同一个 io.ReadFull 错误，在上传接口中是 Error，在心跳检测里可能只是 Warn。级别必须结合场景，不能只看错误值。
