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节省半天排障时间。
以上就是如何使用Go日志输出error信息_Go日志Error记录最佳实践的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1428623.html
微信扫一扫 
支付宝扫一扫 
