zap.atomiclevel 是唯一靠谱的运行时调级方式，需初始化 atomiclevel、传入 core 并调 setlevel；zerolog 依赖 filteredlevelwriter.level 字段热更新；语义分级须在 write/handle 中实现，注意字段归一化、解码还原与并发安全。
zap.AtomicLevel 是唯一靠谱的运行时调级方式
zap.Logger 本身不可变，所有“改级别”的尝试如果没落到 AtomicLevel 实例上，就等于没生效。常见错误是调用 logger.WithOptions(zap.IncreaseLevel())——这只会返回一个新 Logger，且其底层 core 级别和原实例完全一样。
实操必须走三步：
- 初始化时创建
atomicLevel := zap.NewAtomicLevel()，生命周期要长（全局变量或依赖注入容器持有） - 构造
core时传入它：zapcore.NewCore(enc, sink, atomicLevel) - 运行时直接调
atomicLevel.SetLevel(zap.DebugLevel)或atomicLevel.SetLevel(zap.WarnLevel)
注意：若用了自定义 Core 包装器（比如加了语义分析逻辑），必须确保它的 Check 方法里调的是 atomicLevel.Level()，而不是硬编码值或局部变量。
zerolog 动态调级靠 FilteredLevelWriter.Level 字段
FilteredLevelWriter 是 zerolog 原生支持热更新的唯一可靠路径。它不是装饰器，而是真正参与写入决策的 LevelWriter 实现。
关键点：
- 不要用
SetGlobalLevel()控制单个 logger——它只影响未显式指定 level 的新实例，已有 logger 不会响应 - 必须把
FilteredLevelWriter实例暴露出来（比如作为服务配置的一部分），才能在 HTTP handler 或配置监听回调里改它的Level字段 - 改完后下一条日志立即生效，无需重建 logger 或 core
示例片段：writer.Level = zerolog.DebugLevel，只要 writer 是你 logger 所用的 writer 实例，就 ok。
语义分级不能绕过 Write/Handle 方法重写
想根据日志内容（比如 “failed to dial”）动态升为 ERROR，就不能依赖 LevelEnabler 或 Leveler——它们只在日志进入前做静态判断，无法读取 msg 字段。
正确入口只有两个：
- zap 场景：实现自定义
Core，在Write方法里先调语义分析函数，临时替换entry.Level，再调下游core.Write - slog 场景：包装
Handler，重写Handle，用r.Attrs()提取msg字段，分析后构造新slog.Record传给原 handler
切记：分词和规则匹配必须限制在前 200 字符；gojieba 实例非 goroutine-safe，要用 sync.Pool 管理；所有 decode（如 base64、gzip）必须在进分析前完成。
环境变量或配置中心更新后，别忘了刷新字段提取逻辑
动态调级最容易静默失效的地方，不是级别设错了，而是日志内容根本没被送进分析流程。
检查三件事：
- 字段名是否统一？不同服务可能用
"message"、"msg"、"log"传内容，语义分析前必须归一化提取 key - 编码是否还原？HTTP body 里的 JSON、gzip 日志流、base64 编码的 msg，都要在进
Write/Handle前解码并 flatten - 并发是否安全？
gojieba初始化加载的词典可以共享，但分词调用必须隔离，否则 panic 或结果错乱
上线前拿真实日志样本跑一遍端到端链路，比看文档管用十倍。
