zap.NewProduction() 默认采样不可通过环境变量关闭，需手动构造Core：关采样用zapcore.NewNopSampler()，调阈值用zapcore.WithSampledLevel()；采样仅作用于同模板日志，与级别无关。
zap.NewProduction() 默认采样怎么关或调参
zap.NewProduction() 默认开启同模板日志每秒最多记录 100 条，其余丢弃——这不是“可有可无”的优化，而是硬编码在 zapcore.NewSampler 里的策略。想关掉或改阈值，不能靠环境变量或简单配置项，必须手动构造 Core。
常见错误：以为加了 zap.WithLevel(zap.DebugLevel) 就能绕过采样，其实完全无效；采样发生在编码后、写入前，和日志级别无关。
- 关采样：用
zapcore.NewNopSampler()替换默认 sampler - 调阈值：传入自定义
zapcore.SamplerOptions，例如zapcore.WithSampledLevel(zapcore.InfoLevel, 1000)表示 Info 级别每秒最多记 1000 条 - 注意：采样只对同一条格式的日志生效（即相同 message + 相同字段 key），带动态值的字段（如
zap.String("req_id", id)）不影响模板匹配
为什么 zap.Stringer() 一用就 panic
panic 错误信息是 panic: runtime error: invalid memory address or nil pointer dereference，根本不是 zap 本身的问题，而是你传给 zap.Stringer() 的对象指针为 nil，它直接调 .String() 方法时触发空指针解引用。
对比：zap.String() 对 nil 安全，会输出空字符串；zap.Stringer() 假设你传的是有效实现 fmt.Stringer 的非空对象。
立即学习“go语言免费学习笔记（深入）”；
- 高频踩坑场景：HTTP 查询参数用
r.URL.Query().Get("id")返回""，你误判为nil，转成*string后塞进zap.Stringer() - 安全写法：不确定是否为 nil？统一走
zap.String()；真要格式化复杂结构体，先判空再包装，或用zap.Any()配合自定义 marshaler - 调试技巧：加个断点或 log 打印该变量地址，确认是不是
0x0
开发环境用 zap.NewProduction() 输出全是压缩 JSON 怎么办
终端里看到一长串没换行、没颜色、字段缩写（"m" 代替 "msg"）、时间是纳秒整数（"t":1716479999.123456）——这不是“配置没生效”，是你明确用了 zap.NewProduction()，它压根就没打算让人眼读。
它面向的是 fluent-bit、filebeat 这类日志采集器，不是开发者终端。强行在本地用，等于把日志系统当文本编辑器使。
- 正确做法：开发阶段无条件用
zap.NewDevelopment()，它自动启用consoleEncoder、颜色、完整字段名、caller 和堆栈 - 如果非要“看起来像生产但可读”，别改 encoding 为
"json"，那是自废武功；可用zap.NewDevelopment(zap.AddCaller())增强信息，但保留 console 格式 - CI/CD 流水线里跑测试时，若需结构化输出供解析，应单独设环境变量控制 logger 初始化逻辑，而非复用生产配置
上线后 inode 耗尽或日志暴涨，大概率是 development 配置漏上了
线上服务跑半天，df -i 显示 inode 100%，或者单个日志文件涨到 20GB+，基本可以锁定是 zap.NewDevelopment() 被打包进了生产镜像。
它不采样、不压缩字段、默认开 caller 和堆栈展开，单条日志体积通常是 zap.NewProduction() 的 3–5 倍，高频接口下 I/O 直接打满。
- 检查点：确认构建时是否硬编码了
zap.NewDevelopment()，或通过环境变量 fallback 到 development 模式 - K8s 或 systemd 下，即使输出到 stdout，也应优先用
zap.NewProduction()——日志采集器专为 JSON 设计，不需要你额外转文本再切分 - 最稳妥方案：用
zap.Config显式声明所有关键项（Encoding、EncoderConfig、OutputPaths），避免依赖 NewXXX 工厂函数的隐式行为
