zap.Logger比SugaredLogger快50%是因为后者需将printf参数经反射转为Field列表并额外分配内存，而Logger直接接收预构建的强类型Field，零反射、零分配、可内联。
直接用 zap.logger，别用 zap.sugaredlogger 做高频日志；结构化字段必须用 zap.string、zap.int 等强类型构造器，不能拼字符串。
为什么 zap.Logger 比 zap.SugaredLogger 快 50%？
因为 SugaredLogger 在底层仍要将 printf 风格参数（如 "user_id", 123）转成 Field 列表，这一步涉及反射和额外内存分配；而 Logger 直接接收预构建的 Field，跳过解析开销。
- 高频路径（如 HTTP 请求处理、数据库查询钩子）必须用
Logger实例 -
SugaredLogger适合低频调试日志、CLI 工具提示、启动/关闭日志等对性能不敏感场景 - 两者不能混用同一日志语句：比如
logger.Info("msg", zap.String("k", "v"))和sugar.Infow("msg", "k", "v")输出结构一致，但性能差异固定
zap.String、zap.Int 这些函数到底在做什么？
它们不是简单地“包装值”，而是返回一个 zap.Field 结构体，其中包含字段名、值指针、编码器标识——整个过程零分配、无反射、可内联。例如 zap.Int("status", 200) 生成的 Field 在日志写入时直接被 JSON 编码器消费，不经过 fmt.Sprintf 或 map[string]interface{} 中转。
- 切片要用
zap.Strings，不要用zap.Any传[]string，后者会触发反射 - 时间用
zap.Time，别用zap.String("ts", t.Format(...))，前者复用缓冲区，后者每次格式化都分配新字符串 - 错误必须用
zap.Error(err)，它会自动展开err.Error()和栈帧（若启用），比zap.String("err", err.Error())更安全、更省内存
生产环境日志输出到文件时，WriteSyncer 怎么配才不丢日志？
直接用 os.File 当 WriteSyncer 是危险的：进程崩溃时缓冲区未刷盘，最后几条日志就丢了。正确做法是组合 lumberjack.Logger + zapcore.AddSync，并确保 defer logger.Sync() 覆盖主流程出口。
-
lumberjack.Logger提供轮转、压缩、最大保留天数，但它本身不是io.WriteSyncer，需用zapcore.AddSync封装 - 避免把多个
WriteSyncer（如文件 + 控制台）直接塞进multiwrite：同步阻塞会拖慢快路径；应使用zapcore.NewMultiCore并发写入 - 如果启用了采样（
zapcore.NewSampler），注意它只作用于Logger，对SugaredLogger无效
最易被忽略的是 logger.Sync() 的调用时机——它只刷当前 logger 及其所有子 logger 的缓冲区，如果你用 logger.With(zap.String("req_id", id)) 创建了子 logger，必须确保父 logger 的 Sync() 被调用，否则子 logger 日志可能滞留在内存中。
