Zap.Logger 更适合审计日志，因其强类型、零分配设计保障字段严格、低延迟与结构化；需定制 EncoderConfig、独立文件写入、禁用 zap.Any，并注入 trace_id、client_ip、user_id、event_time 四类上下文字段，且须预脱敏敏感信息。
zap.Logger 为什么比 SugaredLogger 更适合审计日志
审计日志的核心要求是：字段严格、不可篡改、写入低延迟、能被下游系统（如 ELK、Loki）稳定解析。SugaredLogger 虽然写法像 fmt.Sprintf，但内部会做 interface{} 反射和字符串拼接，带来额外内存分配和 GC 压力；而 Logger 是强类型、零分配（zero-allocation）设计，字段必须显式用 zap.String、zap.Int64 等构造器传入——这恰好强制你定义清晰的审计 schema。
- 审计字段一旦上线，就不该动态增删或类型漂移，
Logger的编译期类型检查能提前拦截zap.String("user_id", 123)这类错误 -
SugaredLogger的Infow("msg", "key", val)在 key 名拼错时只报 runtime panic，而Logger.Info("msg", zap.String("user_id", id))错误在编译阶段就暴露 - 高并发审计场景下（如每秒千次支付日志），
Logger的吞吐量通常是SugaredLogger的 2–3 倍（实测数据见 zap benchmark suite）
用 zap.NewProduction() 初始化审计 Logger 的真实约束
别直接用 zap.NewProduction() 就完事。它默认把日志输出到 os.Stderr，且时间戳格式为 RFC3339Nano，字段名固定为 ts、level、msg —— 这些对审计不友好。你需要定制 EncoderConfig 和 WriteSyncer：
- 审计日志必须写入独立文件（不能混在 stderr），用
lumberjack.Logger做轮转，避免单文件爆炸：lumberjack.Logger{Filename: "/var/log/app/audit.log", MaxSize: 100, MaxAge: 7} - 字段名要符合审计规范（如公司要求
event_time而非ts，event_type而非msg），需重写EncoderConfig的TimeKey、LevelKey、MessageKey - 禁止使用
zap.Any：它会触发反射序列化，破坏结构化前提；所有业务字段必须有明确类型，比如用户 ID 用zap.Int64("user_id", u.ID)，而非zap.Any("user_id", u.ID)
审计日志必须携带的 4 类上下文字段
光记业务动作（如 "order_created"）不够，审计日志要能回溯“谁、在什么上下文中、做了什么、结果如何”。Zap 不自动注入这些，得你自己封装一层：
-
trace_id和span_id：从 HTTP 请求头或 context 中提取，用zap.String("trace_id", tid)注入，确保跨服务链路可追踪 -
client_ip：从*http.Request.RemoteAddr或 X-Forwarded-For 解析，注意防御伪造，建议用中间件预处理后存入 context -
user_id/account_id：认证后从 JWT 或 session 中获取，**绝不能依赖前端传参**，必须服务端可信源提取 -
event_time：用time.Now().UTC()，而非 zap 默认的纳秒级时间戳（太长，ES 存储浪费）；可通过自定义Encoder截断到毫秒
示例调用：auditLogger.Info("order_paid", zap.String("trace_id", tid), zap.String("client_ip", ip), zap.Int64("user_id", uid), zap.String("order_no", no), zap.Float64("amount", amt))
sync() 调用时机和 panic 风险点
defer logger.Sync() 只适合 main 函数或短生命周期命令行工具。Web 服务中，每个请求都 defer 会导致大量 goroutine 等待 sync，反而拖慢响应。正确做法是：
- 审计日志必须同步刷盘（
WriteSyncer底层已保证），所以不用每次调用后Sync()，但得确保进程退出前有一次全局Sync() - 真正危险的是在
recover()panic 处理中打审计日志：此时程序栈已损坏，logger.Info可能触发二次 panic。解决方案是审计 Logger 单独用一个不带任何 hook 的 bareboneCore，绕过所有采样、hook、error output - 如果审计日志写入失败（如磁盘满），
WriteSyncer.Write会返回 error，但 zap 默认静默忽略。你得包装一层WriteSyncer，在 error 时触发告警（如发 Slack webhook），而不是丢弃
最易被忽略的是：审计日志的字段值若含敏感信息（如身份证号、银行卡号），zap 不做脱敏。你必须在传入前手动替换，例如 zap.String("id_card", maskIDCard(raw)) —— 这步漏掉，合规审计直接不通过。
