zap日志分级由core.check()在最前端拦截，未通过者不格式化直接丢弃；warn未输出因levelenabler过滤，需用zap.atomiclevel实现运行时动态调级，且须确保encoder正确输出level字段。
zap 的日志分级不是靠 if logger.Level() == Debug 这类运行时判断，而是由 core.Check() 在日志写入最前端就拦截掉不满足条件的条目——没通过检查的日志连格式化都不做，直接丢弃。这意味着错误级别设置会直接影响 CPU 和内存开销。
为什么 logger.Warn("msg") 没输出？检查 LevelEnabler 是否生效
常见现象：代码里明明调用了 logger.Warn()，但控制台或文件里完全看不到。根本原因不是函数没执行，而是它在 core.Check() 阶段就被过滤了。
- 默认的
zap.NewProduction()使用zap.LevelInfo，所以Debug和Warn（注意：Warn 是 Info 级别之上的，不会被过滤）都能过；但如果设成了zap.LevelError，Warn就静默丢失 -
DPanic是 debug 模式下的 panic，非 debug 下自动降级为Error，不是独立的“更高级别” - 级别顺序严格为：
Debug ；设为 <code>Warn表示只允许Warn及以上（即Warn、Error、Panic、Fatal） - 不要用
logger.WithOptions(zap.IncreaseLevel())试图动态提级——它只在初始化时起作用，对已创建的Logger实例无效
如何让日志级别可运行时切换？必须用 zap.AtomicLevel
zap.Logger 本身不可变，它的级别由绑定的 core 决定。想改级别，就得让这个 core 持有一个可变的 level 容器。
- 初始化时用
atomicLevel := zap.NewAtomicLevelAt(zap.InfoLevel)创建原子级别实例 - 构造
core时传入该实例：zapcore.NewCore(encoder, sink, atomicLevel) - 后续调用
atomicLevel.SetLevel(zap.DebugLevel)即可立即生效（注意：已进入Check()前的调用不受影响） - 如果封装了自定义
core（比如加了采样或路由逻辑），务必在Check()方法里调用atomicLevel.Level()，而不是硬编码一个值
结构化字段 + 正确 encoder 才能让分级真正“可识别”
Warn 和 Error 日志看起来一样？大概率不是级别没起作用，而是你没看到 level 字段，或者字段样式被覆盖了。
- JSON encoder 默认输出
"level":"warn"或"level":"error"，但如果你用了自定义EncoderConfig却没显式配置EncodeLevel，可能被设成空或误转大写（如"WARN"），导致日志采集工具（filebeat、fluentd）无法正确路由 - 终端输出（console encoder）默认把 level 渲染成不同颜色，但若禁用了 color 或重写了
ConsoleEncoder，也容易忽略区分 - 别用
zap.Any("err", err)替代zap.Error(err)：前者触发反射，后者直接展开错误信息和栈帧（若启用），且字段名固定为error，便于告警规则匹配
最易被忽略的一点：动态调级本身几乎零开销，但级别一降（比如从 Error 切到 Debug），日志量可能指数级增长——尤其当 encoder 是 JSON、sink 是磁盘文件时，IO 和序列化压力会立刻显现。上线前务必在预发环境压测对应级别的日志吞吐能力。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
