调用日志基础：日志级别与格式标准
做日志排查的第一件事，不是盯着报错信息反复看，而是先搞清楚你手里的日志是什么级别、格式是否统一。我当年接手 C_Decrypt 这个项目时，第一眼看到日志文件就懵了——同一行日志里，时间戳有的带毫秒有的不带，线程 ID 直接丢了，函数名全靠猜。那次排查花了我整整两天，后来我强制团队统一了日志标准，效率翻了几倍。
说白了，日志就是程序运行时的“黑匣子”。级别告诉你这事有多严重，格式告诉你怎么快速定位。你想想看，如果连 ERROR 和 WARN 都分不清，你怎么知道该半夜爬起来还是第二天再看？
核心原则：日志级别决定响应策略，日志格式决定排查效率。
1. 日志级别：从 ERROR 到 DEBUG
主流日志库基本都支持这四个级别，咱们按严重程度从高到低说。
| 级别 | 含义 | 典型触发场景 | 我的建议 |
|---|---|---|---|
| ERROR | 程序出现了必须立即处理的故障 | 内存分配失败、密钥解析异常、文件写错误 | 必须告警，收到就要起来看 |
| WARN | 出现了预期之外的状况，但不影响当前流程 | 重试成功、配置项缺失使用默认值、网络超时后恢复 | 日常检查，按优先级处理 |
| INFO | 记录关键业务节点，正常行为 | 调用入口、返回值、模块启动关闭 | 保留，但生产环境慎用过多 |
| DEBUG | 开发调试用，记录详细变量状态 | 循环内每次迭代结果、临时计算中间值 | 生产环境默认关闭 |
这里有个常见的坑。我曾经在排查一个 C_Decrypt 调用失败时，发现团队有人把 DEBUG 级别的日志直接写成了 ERROR，因为“这样更容易看到”。结果生产环境日志瞬间暴涨，磁盘直接打满。所以我说，级别是工程契约，别乱用。
2. 日志格式标准：时间戳、线程 ID、函数名、消息
格式模板我一般推荐这样：
[2025-03-21 14:30:45.123] [TID-1234] [C_Decrypt::DecryptCore] ERROR: RSA解密失败，密钥长度为256字节每个字段都有自己的重要性，我一个个说。
| 字段 | 标准格式 | 为什么重要 | 常见问题 |
|---|---|---|---|
| 时间戳 | yyyy-MM-dd HH:mm:ss.SSS | 确定事件发生的精确时刻，尤其多线程并发时差值毫秒级 | 不带毫秒、时区不统一 |
| 线程 ID | TID-1234 或 0x4D2 | 区分哪个线程出了问题，定位并发冲突 | 忘记打印、ID 格式不固定 |
| 函数名 | 类名::方法名 或 __FUNCTION__ | 快速定位代码位置，避免翻栈 | 宏展开后函数名混乱、C 风格函数不加类名 |
| 消息 | 格式化的、带上下文的描述 | 告知发生了什么，携带关键参数 | 只有“错误”两个字，没有参数值 |
我个人习惯在客户端写日志时，用 __FILE__ 和 __LINE__ 做二次定位，但标准格式里不强制——生产环境这些信息在编译时就能拿到，反而让日志行变长。你想想看，一千万行日志多一个字段就是几兆的额外存储。
__PRETTY_FUNCTION__，它能输出完整的函数签名。我在 C_Decrypt 整改日志时，就用这个替代了手写的 class::method，再也不怕重构后忘记改日志了。
3. 一张图看懂日志体系
下面这张图是我画的日志级别与格式的关系图。你可以看到，ERROR 和 WARN 往往需要额外的处理通道（告警、持久化），而 INFO 和 DEBUG 则更偏向于按条件过滤。格式的各字段就像标签一样，贴在每一条消息上，方便后面做全文检索或可视化分析。
4. 实际案例：C_Decrypt 日志格式不统一带来的排查灾难
还记得我开头说的那个项目吗？当时日志格式是这样的：
[03-21 14:30:45] [1234] decrypt failed: key error
14:30:46.123 [WARN] retry success
ERROR: memory leak in decrypt core三条日志，三种格式。第一条缺年份、缺毫秒、函数名未知；第二条有毫秒但没线程 ID；第三条干脆把 ERROR 当作前缀而不是级别字段。我排查一个死锁问题，想按时间线还原线程执行顺序，结果光对齐时间戳就花了半天。后来我们用正则统一清洗，但总有几条落网的。
教训：日志格式必须在项目启动前约定好，写入代码规范检查。C++ 项目中我推荐使用宏封装，比如 LOG_ERROR(msg) 自动填充时间、线程 ID 和函数名，而不是让每个开发者手写。
我在 C_Decrypt 里最终采用的方案是：
- 使用 spdlog 作为日志库，自定义 pattern：[%Y-%m-%d %H:%M:%S.%e] [%t] [%!] %^%l%$ %v
- 线程ID 用 std::this_thread::get_id() 转字符串
- 函数名用 __PRETTY_FUNCTION__ 而不是硬编码
这套组合拳打下来，后面所有的异常排查基本能在 10 分钟内定位根因。
5. 简单提一下日志格式对排查的影响
你想想看，如果你有三万行日志要过滤，你会怎么搜？我一般这么干：
- 先按级别过滤：
grep '\[ERROR\]'，把最紧急的拉出来 - 再按线程 ID 分组：看哪个线程的 ERROR 最多
- 最后按时间戳排序：还原执行顺序
要是格式不标准，这些步骤全得靠人工猜。所以我才一直强调：日志是工程，不是艺术。统一格式带来的收益，远超你写代码时多打几个宏的功夫。