zap.NewProduction() 不能直接实现分级异步刷盘，因其返回的是同步、单 core、无轮转、无 level 分流能力的 logger，仅支持 JSON 编码、采样和写入 os.Stderr，不具备分级输出到不同文件、异步写入或可靠刷盘能力。
为什么 zap.NewProduction() 不能直接实现分级异步刷盘
因为 zap.NewProduction() 返回的是一个同步、单 core、无轮转、无 level 分流能力的 logger —— 它只做三件事：JSON 编码、采样、写入 os.Stderr。所谓“分级”，它默认只输出 InfoLevel 及以上；所谓“异步”，它连 goroutine 都不启；所谓“刷盘”，它依赖底层 WriteSyncer 是否调用 Sync()，而默认 os.Stderr 是无缓冲且不刷盘的伪同步。
常见错误现象：
• 日志按 level 分到不同文件失败，所有日志挤在同一个 app.log
• 压测时 CPU 空转、QPS 掉半，pprof 显示大量时间卡在 syscall.Write
• 进程突然退出，最后 200ms 的 error 日志消失
- 分级必须靠多
zapcore.Core组合，不是改LevelEnablerFunc就能分文件 - 异步必须显式用
zapcore.NewAsyncCore或手写带双触发（满 + 超时）的 writer，不能靠go logger.Info() - 刷盘可靠性取决于
WriteSyncer实现：裸*os.File不保证落盘，lumberjack.Logger默认也不调file.Sync()
如何用 lumberjack + zapcore.NewAsyncCore 实现按 level 分文件 + 异步刷盘
核心是把“分级”、“异步”、“归档”三件事拆开：分级靠 zapcore.NewTee 合并多个 core；异步靠 zapcore.NewAsyncCore 包一层；归档靠 lumberjack.Logger 提供的切割能力 —— 三者不可互相替代，也不能省略任何一环。
实操建议：
• 每个 level 对应独立 lumberjack.Logger 实例（如 errorWriter、infoWriter），不要共用同一文件句柄
• lumberjack.Logger 的 Filename 必须是绝对路径，且目录需提前 os.MkdirAll
• LocalTime: true 必设，否则中国区服务器生成的备份文件名时间戳全是 UTC，MaxAge 失效
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
MaxSize: 100（MB）比1024更稳：太大导致单文件难排查，太小引发高频切割 IO -
MaxAge: 7和MaxBackups: 30配合使用：保留最近 7 天内生成的所有文件，但总数不超过 30 个（防突发日志暴涨） - 异步 core 必须用
zapcore.AddSync包裹lumberjack.Logger，再套zapcore.Lock，否则多 goroutine 写同一文件会乱序或 panic
zap.Stringer() panic 和异步日志丢失的隐蔽关联
表面看是 zap.Stringer() 传了 nil 指针导致 panic，但线上常因异步机制掩盖了问题：日志 entry 进入 zapcore.NewAsyncCore 的 ring buffer 后，panic 发生在 writer goroutine 中，主业务线程无感知，只看到“某条 error 日志没出现”。更麻烦的是，panic 会导致该 goroutine 退出，后续日志全丢，且无任何错误提示。
典型场景：
• r.URL.Query().Get("id") 返回空字符串 ""，你误判为 nil，转成 *string 后塞进 zap.Stringer()
• json.Unmarshal 失败后返回未初始化结构体指针，直接传给 zap.Any()，内部调 String() 时访问 nil 字段
- 安全做法：不确定是否为 nil？统一用
zap.String()—— 它对 nil 输入返回空字符串"" - 真要用
zap.Stringer()，先判空：if v != nil { logger.Info("xxx", zap.Stringer("v", v)) } - 异步模式下务必加
defer logger.Sync()，并在进程退出前监听os.Interrupt信号主动 flush，否则 buffer 里积压的日志永远不落地
开发与生产环境 logger 初始化不能只靠环境变量切换
很多项目用 if env == "prod" { zap.NewProduction() } else { zap.NewDevelopment() }，这看似合理，实则埋雷：开发时用 zap.NewDevelopment() 输出彩色 console 日志，上线却忘了关掉 caller 和 stacktrace，单条日志体积翻 3 倍；或者生产环境误用 zap.NewDevelopment() 导致 inode 耗尽。
关键区别不在“环境变量”，而在 encoder、writer、level、sampler 四个维度必须显式解耦：
- 开发阶段：必须用
consoleEncoder+os.Stdout+DebugLevel+zap.AddCaller()，禁用采样 - 生产阶段：必须用
jsonEncoder+lumberjack.Logger+InfoLevel+zap.NewSampler(...)，显式加zap.AddCallerSkip(1)如需行号 - 哪怕输出目标都是 stdout（如 K8s），也该用
zap.NewProduction()—— fluent-bit 就认 JSON 格式，不需要你人工切字段
最易被忽略的一点：无论开发还是生产，只要用了 lumberjack.Logger，就必须在进程退出前调 logger.Sync()，否则最后一秒的缓冲日志就永远留在内存里。
