zap.NewProduction()默认只输出到os.Stderr，不支持直接写文件；必须手动构造zapcore.Core并传入自定义WriteSyncer（如lumberjack.Logger），才能安全、结构化地写入文件。
zap.NewProduction() 默认不支持直接写文件，得自己配
zap 本身不内置文件写入能力，NewProduction() 和 NewDevelopment() 都只往 os.Stderr 输出。想写文件，必须手动构造 zapcore.Core，并传入一个能写磁盘的 zapcore.WriteSyncer。
常见错误是直接调用 zap.NewProduction() 后试图“切换输出目标”，结果日志依然刷屏——因为配置已固化，不可变。
- 必须用
zapcore.NewCore()搭配自定义WriteSyncer -
WriteSyncer可以是os.File，但要注意打开模式（需os.O_CREATE | os.O_WRONLY | os.O_APPEND）和同步行为（fsync影响性能） - 结构化字段（
zap.String("user_id", "123")）天然支持，无需额外处理
怎么安全地把日志写进文件而不丢数据
直接用 os.OpenFile 创建文件写入器容易出问题：进程崩溃时缓冲区未刷盘、多 goroutine 并发写导致乱序、日志轮转缺失引发磁盘占满。
推荐用 lumberjack.Logger 封装文件写入器，它自动处理切割、压缩、保留数量——不是 zap 自带的，但已是 Go 日志生态事实标准。
- 安装：
go get gopkg.in/natefinch/lumberjack.v2 - 构造
WriteSyncer：zapcore.AddSync(&lumberjack.Logger{Filename: "app.log", MaxSize: 100, MaxBackups: 5, MaxAge: 28}) - 务必设置
EncoderConfig.EncodeTime，否则时间字段为空或格式错乱（默认用 RFC3339，但 lumberjack 不影响编码逻辑）
结构化日志字段在文件里长什么样
zap 的结构化日志写入文件后仍是 JSON 格式（zap.NewProductionEncoder() 默认行为），每行一个 JSON 对象，可被 ELK、Loki 等直接摄入。
例如这行代码：logger.Info("user login", zap.String("user_id", "u_789"), zap.Bool("success", true))，生成内容类似：
{"level":"info","ts":1716234567.890123,"caller":"main.go:42","msg":"user login","user_id":"u_789","success":true}
- 字段顺序不保证（map 无序），但所有键值对都会保留
- 如果想省略
caller或ts字段，需自定义EncoderConfig并设EncodeCaller/EncodeTime为nil - 避免在字段名里用点号（如
zap.String("req.body.size", "1024")），某些日志系统解析 JSON 时会把点当作嵌套分隔符
为什么 zap.NewDevelopment() 写文件后格式全乱了
NewDevelopment() 用的是 consoleEncoder，输出带颜色、缩进、换行的可读文本，不是合法 JSON。写进文件后无法被结构化解析，也难做字段提取。
- 开发期调试可用
NewDevelopment()+os.Stdout，但写文件必须配zap.NewProductionEncoder()或自定义 JSON encoder - 别试图用
strings.ReplaceAll去“修复” console 输出的 JSON 化——颜色控制符、换行、空格都是有意为之，强行清洗极易破坏字段完整性 - 若真需要开发期也写文件且可读，建议用两个 logger：一个 console 输出到终端，一个 JSON 输出到文件，共用同一 core 或分别配置
结构化日志写文件这件事，关键不在“能不能”，而在“要不要保留结构语义”。一旦选了 JSON 格式，就别回头碰 console encoder；一旦用了 lumberjack，就别自己手写轮转逻辑——边界划清，后面加指标、接告警、做审计才不会突然卡住。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
