生产环境优先用 zap.Logger，它零分配、无反射、直接写结构化日志；仅快速原型或调试时用 zap.SugaredLogger，因其支持 fmt 风格语法但有字符串拼接开销且丢失结构化能力。
zap.Logger 和 zap.SugaredLogger 该选哪个？
生产环境优先用 zap.Logger，它零分配、无反射、直接写结构化日志。只有在快速原型或调试时才考虑 zap.SugaredLogger，它支持类似 fmt 的语法（如 sugar.Infow("user login", "uid", 123)），但底层会做字符串拼接和类型检查，有额外开销。
-
zap.Logger要求显式传字段（zap.String("key", val)），类型安全且快 -
zap.SugaredLogger允许sugar.Infof("hello %s", name)，但会丢失结构化能力 - 同一个
zap.Logger可通过.Sugar()方法临时转成SugaredLogger，别反向转换
如何避免 zap 写日志时阻塞主线程？
默认的 zap.NewProduction() 使用同步写入，磁盘慢或日志量大时会拖慢业务逻辑。必须用 zapcore.NewCore + zapcore.NewSampler + 异步 zapcore.AddSync 组合：
- 用
zapcore.Lock包裹文件句柄防并发写冲突 - 用
zapcore.NewSampler限频（比如每秒最多 100 条 error 日志） - 用
zapcore.NewTee把日志同时发给多个输出（如文件 + Kafka） - 最关键：用
zapcore.AddSync包一层io.MultiWriter或自定义缓冲 writer，不要直接传*os.File
示例关键片段：
file, _ := os.OpenFile("app.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)
core := zapcore.NewCore(
zapcore.NewJSONEncoder(zap.NewProductionEncoderConfig()),
zapcore.Lock(file),
zapcore.InfoLevel,
)
logger := zap.New(core).With(zap.String("service", "api"))
为什么 zap.Error() 有时不打印堆栈？
zap.Error() 只对实现了 error 接口的值调用 Error() 方法，不会自动捕获 goroutine 堆栈。想打完整错误上下文，得配合 errors.WithStack()（来自 github.com/pkg/errors）或 Go 1.13+ 的 fmt.Errorf("xxx: %w", err)，再用 zap.NamedError() 或手动加字段：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 错误本身不含堆栈 →
zap.Error(err)就是纯字符串 - 错误带堆栈（如
errors.WithStack(err)）→ 需要zap.String("stack", fmt.Sprintf("%+v", err)) - 更稳妥：统一用
zap.Any("err", err)，zap 会尝试调用fmt.Formatter接口（前提是错误库支持）
日志字段太多导致性能掉得厉害，怎么精简？
zap 的结构化字段不是免费的 —— 每个 zap.String() 都分配一个 zap.Field 结构体，字段超 10 个时内存和 CPU 开销明显上升：
- 避免在热路径循环里拼一堆字段（如 for range 每次都
logger.Info("item", "id", id, "name", name, ...)） - 提前构造复用的
zap.Field切片：baseFields := []zap.Field{zap.String("service", "api"), zap.Int("pid", os.Getpid())}，每次logger.With(baseFields...).Info(...) - 不要滥用
zap.Any()，它会深度反射，比zap.String()慢 5–10 倍 - 调试期可开
zap.IncreaseLevel(zap.DebugLevel)，但上线必须关掉 debug 级别字段
字段数量和性能不是线性关系，超过 8 个字段后，每多一个字段带来的 GC 压力会指数级放大。真正高频日志（如每秒万级）建议控制在 3–5 个核心字段内。
