Zap 默认不输出完整JSON字段名是因为生产配置启用缩写（如"level"→"l"）以减小日志体积，但影响可读性和K8s日志采集；开发应使用NewDevelopmentEncoderConfig，高频日志须用zap.Logger而非SugaredLogger，复用时需衍生子logger而非修改全局实例，文件输出需正确设置OpenFile标志并调用Sync。
为什么 Zap 默认不输出 JSON 字段名？
因为 zap.NewProductionEncoderConfig() 默认启用了字段名缩写（如 "level" → "l"），这是为减少日志体积做的妥协，但调试时极难读。真实项目里几乎没人直接用默认生产配置跑开发环境。
- 开发阶段务必用
zap.NewDevelopmentEncoderConfig()，它保留完整字段名、带颜色、加调用栈 - 若坚持用生产配置但要可读，手动覆盖
EncoderConfig.LevelKey等字段：cfg.LevelKey = "level" - 字段名缩写在 Kubernetes 日志采集（如 Fluent Bit）里可能引发解析失败——某些 parser 不认
"l": "info"这种格式
zap.Logger 和 zap.SugaredLogger 怎么选？
不是“功能多就用 Sugared”，而是看日志是否需要结构化字段。Sugared 是语法糖，底层仍走 Zap，但所有字段都变成 any 类型，运行时做反射解析，性能差 3–5 倍。
- 高频日志（如 HTTP 请求记录、指标打点）必须用
zap.Logger+zap.String("path", r.URL.Path)显式字段 - Sugared 适合低频、临时调试日志，比如
sugar.Infow("user login", "uid", 123, "ip", "192.168.1.1") - 混用时注意：不能把
zap.Logger直接转成SugaredLogger，得用logger.Sugar()方法获取新实例
如何安全地复用 zap.Logger 实例？
全局单例看似方便，但容易被无意污染——比如某处调用 .With(zap.String("trace_id", ...)) 后，后续所有日志都带上这个字段，且无法撤回。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 避免在 main 包里直接导出全局
Logger变量；改用函数封装：func NewRequestLogger(traceID string) *zap.Logger { return baseLogger.With(zap.String("trace_id", traceID)) } - 中间件或 handler 内应基于传入的 logger 衍生子 logger，而不是修改原始实例
- 测试时用
zaptest.NewLogger(t)替代真实 logger，避免测试间状态污染
为什么 zapcore.WriteSyncer 配置文件输出后没日志？
常见错误是只写了 os.OpenFile 但没设 os.O_APPEND | os.O_CREATE | os.O_WRONLY 标志位，或者忘了调用 logger.Sync() —— Zap 默认异步写日志，进程退出前不 flush 就丢数据。
立即学习“go语言免费学习笔记（深入）”；
- 文件写入必须用
zapcore.AddSync包裹文件句柄：file, _ := os.OpenFile("app.log", os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644); ws := zapcore.AddSync(file) - 进程退出前（如
defer logger.Sync()）或定时调用logger.Sync()，尤其在短命命令行工具里 - 线上服务建议搭配
lumberjack.Logger做轮转，但注意 lumberjack 的MaxSize单位是 MB，不是字节
字段名缩写、异步写入、子 logger 衍生——这三个地方最常被跳过，一漏就卡住排查节奏。
