zap.Logger 日志级别由 core 决定且不可变，动态调级需用 zap.AtomicLevel 配合自建 core；WithOptions 等方法仅影响初始化，不改变已创建 Logger 的级别。
zap.Logger 的日志级别由 core 决定，不能直接改 Logger 实例
zap 的 Logger 本身是不可变的，它的日志过滤逻辑完全委托给底层的 core。所谓“设置级别”，本质是替换或重配置它所持有的 core。直接调用 logger.WithOptions(...) 或试图修改字段，对级别无效。
常见错误现象：logger.Info("test") 仍不输出，即使你“设了 DebugLevel”——大概率是因为新级别没落到实际生效的 core 上。
- 级别控制只在
core.Check()阶段发生，Check返回nil才会继续写入 - 默认的
zap.NewProduction()和zap.NewDevelopment()返回的Logger都绑定了固定级别的core - 想动态调级，必须让
Logger持有可更新的core，比如用zapcore.NewCore()自建，并配合atomic.Level
用 atomic.Level 实现运行时级别切换
zapcore.Level 是一个整数类型，但直接赋值无法触发已有 core 的行为更新。正确做法是使用 zap.AtomicLevel（即 *zap.AtomicLevel），它内部用 atomic.Int32 封装，支持并发安全的读写。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 定义全局或长生命周期的
atomicLevel := zap.NewAtomicLevel() - 创建
core时传入：core := zapcore.NewCore(enc, sink, atomicLevel) - 构造
Logger：logger := zap.New(core) - 运行时切换：
atomicLevel.SetLevel(zap.DebugLevel)或atomicLevel.SetLevel(zap.WarnLevel)
注意：如果用了 zap.WrapCore() 或自定义 core 包装器，需确保其 Check 方法内调用的是 atomicLevel.Level() 而非硬编码值。
为什么 zap.NewDevelopment().WithOptions(zap.IncreaseLevel()) 不起作用
zap.IncreaseLevel() 和 zap.DecreaseLevel() 是用于初始化时“微调”默认级别（如把 DebugLevel 变成 InfoLevel），它们只影响新构建的 core，不是运行时指令。一旦 Logger 创建完成，这些选项就失效了。
典型误用场景：
- 启动后反复调用
logger.WithOptions(zap.IncreaseLevel())—— 这只会返回一个新Logger，且其core级别和原 logger 完全一样 - 以为
WithOptions是 setter，其实它是 builder 模式，每次调用都生成新实例，不改变原实例 - 没意识到
NewDevelopment()内部已锁定为DebugLevel，IncreaseLevel()在它之后调用等于 +1 →InfoLevel，但仅限初始化那一次
生产环境动态调级要小心 sink 和 encoder 的开销
动态调级本身几乎零开销，但级别降低（比如从 ErrorLevel 切到 DebugLevel）可能导致日志量激增，尤其当 encoder 是 json、sink 是文件或网络时，I/O 和序列化压力会立刻显现。
建议操作：
- 避免在高 QPS 接口里直接切到
DebugLevel，优先用带字段的条件日志：logger.Debug("slow_path", zap.Duration("took", d)) - 如果必须全局降级，搭配采样器：
core = zapcore.NewSampler(core, time.Second, 100)，防刷屏 - 文件 sink 建议用
lumberjack.Logger并设MaxSize，否则低级别日志可能撑爆磁盘 - 调试结束后务必切回原级别，
atomicLevel.SetLevel(zap.InfoLevel)—— 这步容易被遗忘
真正麻烦的从来不是怎么切，而是切完忘了切回去，或者没评估下游 sink 是否扛得住。
