日志级别应定义为整数常量（debug=0、info=1、warning=2、error=3、fatal=4），避免枚举或字符串；优先级随数值增大而升高；运行时动态调级需确保线程安全并同步所有logger及sink级别。
日志级别怎么定义才方便开关和比较
直接用整数常量（比如 DEBUG=0、INFO=1）最稳妥，别用枚举或字符串——前者比较慢，后者没法直接参与数值判断。主流库（如 spdlog、glog）都这么干，你也照搬就行。
关键点是：级别值越小，优先级越低；DEBUG 通常设为最低（0），ERROR 设为较高（3 或 4），这样 logger->set_level(level) 设置后，所有低于该值的日志自动被过滤。
-
DEBUG→ 0，INFO→ 1，WARNING→ 2，ERROR→ 3，FATAL→ 4 - 避免跳号（比如
DEBUG=10、INFO=20），虽然 log4j 这么做，但在 C++ 里纯属给自己加转换负担 - 全局定义建议用
constexpr int，而不是宏，便于 IDE 跳转和类型检查
如何在运行时安全地修改当前 logger 的级别
不是所有日志库都支持线程安全的动态调级。spdlog 支持，但得用 spdlog::set_level() 或实例方法 logger->set_level()；glog 必须调用 google::SetLogDestination() 配合环境变量，实际并不真正“动态”。
最容易踩的坑是：多线程下直接调 set_level() 而没确认是否线程安全。spdlog 的 set_level() 是原子操作，但如果你自己封装了 logger 单例，又没加锁，就可能漏日志或级别错乱。
- 推荐用 spdlog：调
spdlog::default_logger_raw()->set_level(spdplog::level::debug) - 如果用了多个 logger 实例，必须对每个调用
set_level()，不能只设 default - glog 没有运行时 API 改级别，只能靠
FLAGS_minloglevel+google::InitGoogleLogging()重初始化（不推荐，会清空已有 sink）
怎样让日志级别能被配置文件或命令行控制
硬编码级别等于放弃运维能力。得在启动时读配置，再设置 logger。常见做法是解析 JSON/YAML/INI，提取 level 字段，映射到对应 spdlog::level::xxx 枚举值。
注意字符串到级别的转换容易出错：大小写、前缀（"debug" vs "DEBUG"）、拼写错误都会导致 fallback 到默认级别，且无提示。
- 用 spdlog 自带的
spdlog::level::from_str("info")，它忽略大小写，返回spdlog::level::info或抛异常 - 命令行参数建议用
std::string接收，再转，别用enum直接绑定 argparse（多数 C++ CLI 库不支持 enum 自动解析） - 配置变更后，别忘了同步更新所有 logger 实例，尤其你用了
spdlog::stdout_color_mt("app")这类命名 logger
为什么改了级别却没生效？几个典型原因
最常见的是日志语句本身用了静态判断，比如 if (level >= DEBUG) LOG_DEBUG(...) —— 这种手写日志宏完全绕过了 logger 的级别控制逻辑，改了 set_level() 也没用。
另一个隐形问题是 sink 的 level 被单独设置了。spdlog 允许给每个 sink（如 file_sink、stdout_sink）设独立 level，如果 sink level 比 logger level 更高，那日志照样被丢弃。
- 检查是否用了自定义宏包裹
LOG_DEBUG，确认它最终调的是 logger 的debug()方法，而不是条件编译 - 用
logger->sinks()遍历所有 sink，打印各自sink->level()，确保没被意外覆盖 - 如果用了 async logger，级别变更立即生效，但正在排队的日志可能按旧级别处理——这是正常异步行为，不是 bug
动态调级真正难的不是 API 调用，而是保证整个日志链路（宏 → logger → sink → formatter）都尊重同一套 level 规则。漏掉任意一环，就会出现“明明设了 DEBUG 却看不到 debug 日志”的情况。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
