Kratos 日志级别不能直接用 setLevel 修改，因其 Logger 接口无状态、纯函数式；需通过 log.Filter + 原子变量（如 atomic.Value）配合配置监听实现动态调整。
kratos 日志级别不能直接用 setLevel 修改
kratos 的 log.Logger 接口不提供类似 Logback 的 setLevel() 方法，也没有内置的运行时级别开关。它的 Log(level Level, keyvals ...interface{}) 是纯函数式调用，level 由调用方传入，底层 logger 实现只负责输出，不维护状态。所以你不能像 Spring Boot 那样通过 loggingSystem.setLogLevel("com.example", DEBUG) 动态改包级别。
必须靠 Filter + 全局变量或配置监听实现动态控制
真正可行的动态调整方式，是把日志过滤逻辑前置到 log.Filter 层，结合外部信号（如配置中心变更、HTTP 接口、文件轮询）实时更新一个共享的 currentLevel 变量。示例关键点：
-
log.NewFilter(logger, filterFunc)中的filterFunc必须闭包捕获可变的 level 变量（推荐用atomic.Value或sync.RWMutex保护） - filter 函数返回
true表示放行，false表示丢弃；例如：return levelVal.Load().(log.Level) - 暴露 HTTP 接口（如
POST /admin/loglevel?level=debug）修改该变量，无需重启进程 - 注意：kratos 的
log.LevelDebug等常量是 int 类型，值越小级别越低（LevelDebug=0,LevelInfo=1,LevelWarn=2），和 Logback 语义一致但数值方向相反
用 Helper 包装后无法绕过 Filter 控制
业务代码里写的 h.Debug("msg") 最终仍会走到你注册的 Filter，所以只要 Filter 逻辑生效，所有 Helper 调用都会被统一拦截。这点和 SLF4J + Logback 的 logger-level 绑定不同——kratos 没有 per-logger 级别树，只有全局过滤入口。容易踩的坑：
- 误以为
log.With(...)或log.NewHelper(...)创建新实例就能绕过 Filter —— 实际上 Filter 是绑定在底层Logger上的，Helper 只是语法糖 - 在多个 goroutine 并发修改 level 变量却没加锁，导致过滤行为不稳定
- 忘记在 Filter 函数里处理
lvl == log.LevelNone或lvl == log.LevelAll边界情况
EDAS/Arms Agent 方案对 Kratos 不适用
阿里云 EDAS 的「动态日志配置」依赖 JVM agent 注入和 log4j2/logback 的 XML 解析器，kratos 是 Go 程序，无字节码增强能力，也不解析 XML/YAML 配置文件来控制日志行为。试图挂载 ArmsAgent 或启用 EDAS 动态日志功能，只会静默失败。Go 生态中目前没有成熟、开箱即用的类 Logback-config-reload 方案，必须自己实现过滤+信号监听闭环。
