Go项目应选zap而非log：标准库log仅适合脚本，zap性能更高、支持分级/结构化/字段注入；开发用Debug配置，生产用Production；ERROR需立即告警，WARN需抽检，INFO记正常节点，DEBUG仅限开发；字段命名须规范统一，避免嵌套；文件输出需lumberjack滚动策略（MaxSize+MaxAge+MaxBackups），ERROR单独文件。
Go项目里该用log还是zap？别直接抄模板
新手常以为“日志就是log.Println打几行”，结果上线后发现：查问题时找不到ERROR堆栈、日志混在DEBUG里淹没了、磁盘被滚动日志撑爆。Go标准库log够用，但只适合单文件脚本；真实项目必须分级+输出控制+结构化，zap是当前最稳妥的选择——它不依赖反射、性能压测比logrus高3–5倍、原生支持Level开关和字段注入。
别一上来就配zap.NewProduction()，开发期要看到DEBUG，生产才关掉；也别迷信“自动JSON格式”，非结构化日志（比如纯字符串错误描述）用logger.Info("failed to connect", zap.String("addr", addr))比拼接字符串更安全。
ERROR和WARN怎么分？看是否需要人工干预
分级不是按严重程度拍脑袋，而是按后续动作划分：
-
ERROR：服务已不可用或数据已损坏，必须立刻告警（如数据库连接永久失败、写入关键表返回sql.ErrNoRows以外的错误） -
WARN：异常发生但服务还能继续，需人工抽检（如第三方API超时重试成功、缓存未命中率突然升到80%） -
INFO：正常流程节点，用于确认路径走对了（如“用户登录成功”、“订单状态更新为paid”） -
DEBUG：仅开发/测试环境开启，含敏感值或高频调用（如HTTP请求头、SQL查询参数）
常见错误：把HTTP 404打成ERROR——这是业务预期行为，应归INFO；把空指针panic前的日志打成WARN——panic本身已是ERROR信号，前置日志至少得是ERROR。
如何让日志真正可检索？字段命名不能口语化
结构化日志的价值在于ELK或Loki里能filter，字段名乱写等于白加：
- 用
user_id，别用uid或the_user_id - 错误码统一用
error_code，别一会code一会errCode - 耗时统一用
duration_ms（毫秒整数），别混用took、latency、cost - 避免嵌套字段：
zap.Object("req", req)会序列化整个struct，可能含私有字段或循环引用；拆成zap.String("req_path", r.URL.Path)等原子字段
logger.Error("db query failed",
zap.String("sql", "SELECT * FROM users WHERE id = ?"),
zap.Int64("user_id", userID),
zap.String("error", err.Error()),
zap.Int("duration_ms", int(elapsed.Milliseconds())))日志输出到文件时，滚动策略最容易漏配置
zap本身不带文件滚动，得靠lumberjack.Logger桥接。新手常只设MaxSize，结果半夜磁盘写满：
- 必须同时配
MaxAge（如7天）和MaxBackups（如30个），否则旧日志永不清 -
LocalTime: true一定要开，否则UTC时间在日志分析时对不上监控告警时间 - Windows下路径分隔符用
/而非，lumberjack内部用filepath.Join处理，硬写"logs\app.log"可能触发open权限错误
另外，别把所有级别日志塞进同一个文件——ERROR单独写error.log，方便运维用tail -f error.log盯屏；DEBUG日志量大，建议关掉或异步写入。
分级这事，最难的不是选库或写字段，而是团队对每个logger.Warn背后是否真要人看达成共识。上线前拉一次日志review，比写一百行配置管用。
