zap.AtomicLevel 是唯一能安全运行时切级的方案，因其基于 *atomic.Int32 封装，Check() 实时读取级别；需手动构造 core 并确保所有 logger 共享同一 AtomicLevel 实例。
zap.AtomicLevel 是唯一能安全运行时切级的方案
标准库 log 没有级别概念，logrus.SetLevel() 非原子、slog 的 Level 字段只在 handler 初始化时读一次——真要热切，只有 zap.AtomicLevel 能扛住高并发写入。它本质是 *atomic.Int32 封装，每次 Check() 都实时读取当前值，不是缓存也不是硬编码。
常见错误现象：
- 用
zap.NewProduction()初始化后，再调atomicLevel.SetLevel(zap.DebugLevel)—— 没用，因为返回的*Logger内部 core 并不持有你创建的AtomicLevel - 把
atomicLevel定义在函数内，被 GC 回收，后续SetLevel()完全无效果 - 多个 goroutine 同时设不同级别，但没确认底层是否线程安全（其实 zap 已保证，但你自己包的 core 可能没透传）
必须自己构造 core，不能依赖 NewProduction/NewDevelopment
zap.Logger 本身不可变，日志过滤逻辑完全委托给底层 core。所谓“动态调级”，本质是让 core.Check() 每次都去读一个可变的 level 值。而 zap.NewProduction() 和 zap.NewDevelopment() 返回的 logger 都绑定了固定级别的 core，无法后期更新。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 定义长生命周期的
atomicLevel := zap.NewAtomicLevel() - 手动构建 core：
core := zapcore.NewCore(encoder, writer, atomicLevel) - 用该 core 构造 logger：
logger := zap.New(core) - 运行时切换：
atomicLevel.SetLevel(zap.WarnLevel)或atomicLevel.SetLevel(zap.DebugLevel)
注意：如果你用了 zap.WrapCore() 或自定义 wrapper，必须确保其 Check() 方法里调的是 atomicLevel.Level()，而不是写死某个常量。
采样和动态调级共存时的执行顺序很关键
采样（SamplingConfig）是在级别过滤之后发生的。也就是说，logger.Info() 先过 atomicLevel.Level() 判断是否允许输出，再进采样器决定是否丢弃。但 logger.Error() 默认绕过采样——这不是 magic，而是 zap 内部对 ErrorLevel 以上做了豁免。
容易踩的坑：
- 以为开了采样就自动降低所有日志量，结果
Error日志照常爆炸式输出 - 在采样前就执行了开销大的字段构造，比如
zap.String("user_id", heavyCalcUserID())—— 即使这条日志最终被采样丢弃，函数仍被执行了 - 正确做法是用惰性求值：
zap.Stringer("user_id", lazyUserGetter)，只在真正需要写入时才计算
生产环境切到 DebugLevel 前必须评估 sink 和 encoder 开销
动态调级本身几乎零开销，但级别下调（如从 WarnLevel 切到 DebugLevel）可能引发日志量激增。尤其当 encoder 是 JSON、sink 是文件或网络时，CPU 和 I/O 压力会立刻显现。
建议动作：
- 压测验证：用真实流量模拟切级后的吞吐与延迟变化
- 限制 scope：不要全局切级，优先通过
logger.With(zap.String("module", "payment"))分模块控制 - 配采样兜底：对高频低价值日志（如 HTTP trace 打点）单独配
SamplingConfig{Initial: 50, Thereafter: 500}
最易被忽略的一点：动态调级生效的前提是所有日志调用路径都经过同一个 AtomicLevel 实例。如果服务里混用了多个 logger（比如 HTTP 中间件、gRPC 拦截器、业务 handler 各自 new 了一个），那改一个 level，其他地方根本不受影响。
