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"没用。要回答：谁调的？在哪发生的？输入是什么？
Github Stars Analyzer
下载
抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...
- 在关键函数入口/出口加上下文：比如处理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节省半天排障时间。
