Go 标准库 log 包不支持错误级别和结构化输出，无法区分严重性、筛选 ERROR、保留错误链及上下文；zap 可解决此问题，支持级别标识、字段注入、自动展开 error 堆栈与因果链。
Go 标准库的 log 包本身不支持错误级别（如 ERROR/WARN/INFO）或结构化输出，直接用它打“错误日志”容易掩盖问题本质——你需要的是带上下文、可过滤、能区分严重性的错误记录能力。
为什么不能只用 log.Println 记录错误
它把所有输出扁平化为字符串，没有级别标识，无法单独筛选 ERROR；不自动包含时间戳、调用位置（log.SetFlags(log.Lshortfile) 可补但有限）；更关键的是，它和 fmt.Printf 几乎等价，丢失了错误链（error 类型本身携带的堆栈和因果信息）。
- 常见错误现象：
log.Println(err)输出connection refused，但不知道是哪次 HTTP 调用、哪个 URL、发生在哪个 goroutine - 使用场景：HTTP handler 中捕获
io.EOF或数据库超时，需要和业务日志隔离并告警 - 性能影响：标准
log是同步写磁盘，默认无缓冲，高并发下易成瓶颈
用 zap 实现带错误级别的结构化日志
zap 是目前 Go 生产环境最主流的选择，性能高、支持字段注入、原生区分 Warn/Error/DPanic 级别，并能直接传入 error 值提取堆栈。
- 安装：
go get -u go.uber.org/zap - 基础用法：用
zap.Error(err)而不是zap.String("err", err.Error())，前者会自动展开Unwrap()链和StackTrace()（需配合github.com/pkg/errors或 Go 1.13+ 的%w） - 示例：
logger, _ := zap.NewProduction() defer logger.Sync() if err := doSomething(); err != nil { logger.Error("failed to process item", zap.String("item_id", item.ID), zap.Error(err), // ← 关键：保留原始 error 结构 zap.Int("attempt", 3), ) } - 注意：默认
NewProduction()输出 JSON，若需控制台可读，改用zap.NewDevelopment()；字段名不要用空格或特殊字符，否则下游解析（如 ELK）易出错
如何在错误传播中保留日志上下文
仅靠日志库不够——如果错误本身没携带足够信息，再好的日志器也记不出关键线索。必须在错误构造阶段就注入上下文。
立即学习“go语言免费学习笔记（深入）”；
- 避免：
return errors.New("read failed")—— 完全丢失路径、参数、时间 - 推荐（Go 1.13+）：
return fmt.Errorf("read %s: %w", filename, io.ErrUnexpectedEOF)，让zap.Error()能展开完整链 - 补充上下文字段：在 handler 层用
zap.String("req_id", r.Header.Get("X-Request-ID"))绑定请求生命周期，而不是塞进错误消息里 - 陷阱：用
errors.Wrapf(err, "xxx")时，若err已含堆栈，重复包装会导致冗余；建议只在跨包边界或协议转换点做一次包装
何时需要自定义错误日志中间件（而非每处都写 logger.Error）
HTTP 服务中大量重复的错误日志逻辑（如统一记录 status code、耗时、path）适合抽成中间件，但要注意错误是否已被处理。
- 典型模式：在中间件末尾检查
w.(ResponseWriter).Status() >= 400，再结合ctx.Value()中预设的 trace ID 和请求元数据打日志 - 危险操作：中间件里对
err调用logger.Error后又返回给上层，导致同一错误被记两次（一次中间件、一次 handler 内显式 log） - 更安全的做法：handler 内用
return fmt.Errorf("api: %w", err)向上抛，由顶层 panic 恢复 + 日志器统一捕获（配合recover()和zap.Desugar().DPanic） - 性能提醒：中间件中避免在日志字段里做耗时操作（如调用
time.Now().Zone()多次），提前算好或用zap.Time一次性注入
真正难的不是选哪个日志库，而是决定哪些错误值得记录、哪些该熔断、哪些应静默丢弃——错误日志系统最终服务于可观测性决策，不是越全越好。
