log.Printf 不适合生产错误监控，因其输出到 stderr、无结构化字段、无法区分错误级别和服务信息，且 log.Fatal 会导致进程退出而无法上报错误。
为什么 log.Printf 不适合生产环境的错误监控
它默认输出到 stderr，没有结构化字段，无法区分错误级别、服务名、请求 ID 或堆栈；日志分散在各处，没法被 ELK 或 Loki 自动采集。更麻烦的是，一旦用了 log.Fatal，进程直接退出，连上报错误的机会都没有。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 禁用所有裸调用的
log.Printf/log.Println，尤其在 HTTP handler 或 goroutine 中 - 错误发生时，优先用
errors.WithStack（来自github.com/pkg/errors）或 Go 1.17+ 的fmt.Errorf("...: %w", err)保留原始堆栈 - 记录错误前，确保上下文里有
request_id、service_name等关键字段，可借助context.WithValue或中间件注入
如何用 zerolog 实现结构化错误日志输出
zerolog 轻量、零分配、原生支持 JSON，是目前 Go 生态中最常用于集中日志的库。关键是把错误对象转成可序列化的字段，而不是简单 .Str("err", err.Error())。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
zerolog.Error().Err(err).Msg("db query failed")，它会自动展开err的类型、消息和堆栈（需启用zerolog.ErrorStackMarshaler） - 初始化 logger 时绑定静态字段：
zerolog.New(os.Stdout).With().Str("service", "auth-api").Timestamp().Logger() - 避免在日志中手动拼接字符串，比如
log.Info().Msg("user " + uid + " login ok")，应改用.Str("user_id", uid).Msg("login ok")，方便后续按字段过滤
怎样把错误日志实时发到 Loki 或 ELK
Go 程序本身不直接推日志到 Loki/ELK；正确做法是写本地 JSON 日志文件，再由 promtail（Loki）或 filebeat（ELK）采集转发。强行在代码里集成 HTTP 客户端推送，反而容易阻塞主流程、丢失日志、拖慢响应。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
os.OpenFile创建带轮转的日志文件（如用lumberjack.Logger），输出到/var/log/myapp/error.json - 确保每行是合法 JSON，且末尾无逗号——
zerolog默认就是单行 JSON，开箱即用 -
promtail配置里指定pipeline_stages解析level和err字段，再打上job="myapp"标签，Loki 就能按 error 级别聚合告警
错误监控绕不开的三个埋点位置
不是所有错误都值得告警。真正要监控的，是那些暴露服务健康状态、影响用户路径、或暗示底层依赖异常的问题。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- HTTP handler 入口：记录
status >= 500的响应，并带上method、path、duration_ms字段 - 数据库操作后：检查
err != nil且!errors.Is(err, sql.ErrNoRows)，后者是业务正常分支，不该进错误流 - 第三方 API 调用失败：除了
err，还要记录http_status和upstream（如 "payment-gateway-v2"），便于快速定位故障域
最容易被忽略的是：没对 panic 做 recover 日志。哪怕用了 http.Server.ErrorLog，也得在中间件里加 defer func() { if r := recover(); r != nil { log.Error().Interface("panic", r).Stack().Send() } }()。否则 goroutine 挂了，日志里连痕迹都没有。
