如何使用Go日志输出error信息_Go日志Error记录最佳实践

Go标准库log包不区分日志级别，有效error日志关键在于可定位、可追溯、含上下文、保错误链；推荐用log.Printf("[ERROR] %v", err)格式，避免log.Println(err)或滥用log.Fatal；需区分预期错误（warn/info）与异常错误（error），并优先采用结构化日志输出error字段。

Go标准库的log包本身不区分日志级别（如debug、info、error），但记录错误信息时，关键不是“打上error标签”，而是确保错误可定位、可追溯、含上下文、不丢失原始错误链。真正有效的error日志，核心在于怎么记录，而不是用哪个函数名。

用log.Printf或log.Print + 显式前缀标记error

标准log包没有log.Error，但你可以用log.Printf加统一前缀，让error日志在文本中一眼可辨：

• 推荐格式：log.Printf("[ERROR] %v", err) 或 log.Printf("[ERROR] failed to open file %q: %v", filename, err)
• 避免只写log.Println(err)——缺少语义，无法快速过滤；也别用log.Fatal代替日志，它会直接退出程序，不适合常规错误记录
• 如果用了第三方日志库（如zap、zerolog），优先使用其Error()方法，并传入err字段（如logger.Error().Err(err).Str("path", p).Msg("read failed")）

永远记录错误发生的位置和上下文

只记"failed to parse JSON"没用。要回答：谁调的？在哪发生的？输入是什么？

• 在关键函数入口/出口加上下文：比如处理HTTP请求时，记录method、path、user_id（脱敏后）、request_id
• 用fmt.Errorf包装错误并追加上下文：return fmt.Errorf("parse config file %q: %w", path, err)，再配合%+v（需用github.com/pkg/errors或Go 1.13+的%+v）打印堆栈
• 简单场景下，用log.Printf("[ERROR] %s:%d %v", filepath.Base(file), line, err)手动加文件行号（可通过runtime.Caller(1)获取）

区分“预期错误”和“异常panic”

不是所有err != nil都要当严重错误日志。I/O超时、用户参数错误、404等是业务流程一部分，应记录为warn或info；而数据库连接突然断开、配置加载失败、nil指针解引用才该标为error。

• 示例：HTTP handler中json.Unmarshal失败 → 记为[WARN] invalid JSON in request body（返回400）
• 但若os.Open("config.yaml")失败且该文件必须存在 → 记为[ERROR] missing required config file（可能需告警）
• 遇到不可恢复的逻辑错误（如switch缺default且值非法），可用log.Panicf或panic，但仅限开发/测试阶段；生产环境建议转为error日志 + 健康检查探活

结构化日志 + 错误字段是进阶刚需

纯文本日志查错慢。现代服务推荐结构化日志（JSON格式），尤其把error作为独立字段输出：

• 用zerolog：logger.Err(err).Str("action", "save_user").Int64("user_id", id).Send() → 输出包含"error":"invalid email format"和"action"等键值
• 用zap：logger.Error("failed to save user", zap.Error(err), zap.Int64("user_id", id))
• 这样日志系统（如Loki、ELK）能自动提取error字段做聚合、告警、趋势分析

基本上就这些。不复杂，但容易忽略上下文和结构化——一次清晰的error日志，往往比五次模糊的print节省半天排障时间。