3、日志等级与分类：定义DEBUG、INFO、WARN、ERROR、FATAL等级别及触发条件
日志等级这件事，说起来简单，做起来其实挺讲究的。我见过不少项目，日志等级定义得模棱两可，结果出了问题，翻半天日志也找不到关键线索。说白了，日志等级就是给每条日志贴一个“严重程度”的标签，告诉看日志的人——这条消息到底有多重要。
在车规级系统里，这个标签尤其关键。你想想看，一辆车在路上跑，ECU每秒产生成千上万条日志。如果每条都当ERROR打，那ERROR就失去了意义。反过来，如果FATAL级别的日志被淹没了，那后果可能很严重。
3.1 五大日志等级的定义
我个人习惯把日志分成五个等级，从低到高依次是：DEBUG、INFO、WARN、ERROR、FATAL。每个等级都有明确的语义和触发条件。
| 等级 | 数值 | 语义 | 典型触发条件 |
|---|---|---|---|
| DEBUG | 0 | 调试信息，开发阶段使用 | 变量值打印、函数入口/出口、中间计算结果 |
| INFO | 1 | 正常运行时的重要事件 | 模块初始化完成、状态切换、周期性心跳 |
| WARN | 2 | 异常但系统可继续运行 | 传感器读数超阈值、通信重试、资源接近上限 |
| ERROR | 3 | 功能受损，需人工介入 | 通信超时、校验失败、配置错误 |
| FATAL | 4 | 系统不可恢复，需立即处理 | 看门狗超时、内存越界、安全机制触发 |
核心原则：数值越小，日志越详细；数值越大，日志越紧急。生产环境中，通常只输出WARN及以上级别的日志。DEBUG和INFO只在开发调试阶段开启。
3.2 各等级的详细说明与触发条件
3.2.1 DEBUG（调试）
DEBUG级别的日志，说白了就是给开发者自己看的。我在项目中遇到过，有些同事喜欢把DEBUG日志写得特别长，恨不得把整个数据结构都打印出来。嗯，这里要注意——DEBUG日志虽然不进入生产环境，但写多了会影响系统性能，尤其是在高频调用的函数里。
触发条件：
- 函数调用时打印参数值
- 循环迭代中的中间变量
- 条件分支的走向判断
- 状态机的状态变化
// 示例：DEBUG日志的使用
void can_message_handler(can_frame_t *frame) {
DEBUG_LOG("CAN frame received: id=0x%x, dlc=%d", frame->id, frame->dlc);
if (frame->id == 0x123) {
DEBUG_LOG("Matched filter ID 0x123, processing...");
// 处理逻辑
}
}3.2.2 INFO（信息）
INFO级别的日志，记录的是系统正常运行时的“里程碑”事件。我建议，每个模块在初始化成功、状态切换、关键任务完成时，都打一条INFO日志。这样在排查问题时，可以快速定位系统运行到了哪个阶段。
触发条件：
- 系统启动完成，进入主循环
- 通信链路建立成功
- 传感器自检通过
- 固件版本号打印
// 示例：INFO日志的使用
void system_init(void) {
// 初始化CAN总线
can_init();
INFO_LOG("CAN bus initialized successfully");
// 初始化传感器
sensor_init();
INFO_LOG("All sensors passed self-check");
// 进入主循环
INFO_LOG("System entering main loop, version=%s", FIRMWARE_VERSION);
}3.2.3 WARN（警告）
WARN级别的日志，是我个人觉得最容易被忽视的。很多开发者觉得“反正系统还能跑，先不管”。但我在项目中吃过亏——有一次，一个传感器偶尔报WARN，大家都没当回事，结果几个月后这个传感器彻底失效了。你想想看，WARN其实是在告诉你：系统虽然还能跑，但已经不在最佳状态了。
触发条件：
- 传感器读数超出正常范围但未到故障阈值
- 通信重试次数超过预设值
- 内存使用率超过80%
- 任务执行时间接近超时上限
避坑指南：我曾经见过一个项目，WARN日志被滥用了。代码里到处都是WARN，连变量名拼写错误都打WARN。结果真正重要的警告反而被淹没了。记住：WARN只用于“系统能继续运行，但需要关注”的情况。
3.2.4 ERROR（错误）
ERROR级别的日志，意味着某个功能已经受损了。比如某个传感器通信断了，系统虽然还能用其他传感器替代，但精度下降了。这时候必须记录ERROR，并且通常需要触发某种降级策略。
触发条件：
- 通信超时（重试后仍失败）
- 数据校验失败（CRC、Checksum等）
- 配置文件解析错误
- 任务执行超时
// 示例：ERROR日志的使用
int read_sensor_data(sensor_t *sensor) {
for (int retry = 0; retry < MAX_RETRY; retry++) {
if (sensor_read(sensor) == SUCCESS) {
return SUCCESS;
}
WARN_LOG("Sensor read failed, retry %d/%d", retry + 1, MAX_RETRY);
}
ERROR_LOG("Sensor %d read failed after %d retries", sensor->id, MAX_RETRY);
return FAILURE;
}3.2.5 FATAL（致命）
FATAL级别的日志，是最高级别的警报。一旦触发，意味着系统已经无法继续安全运行了。在车规级系统中，FATAL日志通常伴随着系统复位或安全状态切换。我记得有一次，一个同事在代码里把FATAL当ERROR用，结果系统动不动就复位。嗯，这显然是不对的。
触发条件：
- 看门狗超时（WDT reset）
- 内存访问越界（MPU/MMU异常）
- 安全机制触发（如E2E校验失败）
- 关键硬件故障（如电源失效）
个人经验：FATAL日志触发后，一定要在复位前把关键上下文保存下来。我习惯在FATAL处理函数中，先把日志刷到非易失存储（如EEPROM或Flash），然后再执行复位。否则复位后什么线索都丢了。
3.3 日志等级与过滤策略
在实际项目中，我们不会把所有等级的日志都输出。生产环境中，通常只输出WARN及以上级别的日志。DEBUG和INFO只在开发调试阶段开启。这个过滤策略，说白了就是“按需输出”。
// 日志等级过滤示例
#define LOG_LEVEL LOG_LEVEL_WARN // 生产环境配置
void log_output(int level, const char *fmt, ...) {
if (level < LOG_LEVEL) {
return; // 低于配置等级的日志直接丢弃
}
// 实际的日志输出逻辑
}重要提醒：日志等级过滤是在编译时还是运行时决定，取决于你的性能要求。车规级系统通常建议编译时过滤，因为运行时判断会带来额外的CPU开销。但如果你需要动态调整日志等级（比如通过诊断命令），那就得用运行时过滤。
3.4 知识体系结构图
下面这张图，是我梳理的日志等级与分类的核心逻辑。你可以把它当作本章节的“地图”。
3.5 实际项目中的注意事项
最后，我想分享几个我在项目中踩过的坑，希望能帮你少走弯路。
- 等级不要滥用：我曾经见过一个项目，所有日志都打ERROR，结果真正出问题时，根本分不清哪个是致命的。记住：DEBUG就是DEBUG，FATAL就是FATAL，别混用。
- 触发条件要明确：每个等级的触发条件，最好在项目初期就定义清楚。我习惯写一个《日志等级定义文档》，贴在团队Wiki上，大家照着执行。
- 考虑性能开销：DEBUG日志虽然只在开发阶段开启，但如果代码里到处都是DEBUG_LOG，编译出来的代码体积会变大。我建议用宏来控制，编译时直接去掉。
- FATAL要留后路：FATAL触发后，系统通常要复位。但复位前，一定要把关键信息保存下来。我习惯在FATAL处理函数中，先刷日志到Flash，再执行复位。
一个小技巧：在定义日志等级时，可以预留一些“中间等级”。比如在WARN和ERROR之间，可以加一个NOTICE等级。这样在需要更细粒度控制时，就不用大改代码了。
好了，关于日志等级与分类，就讲到这里。记住：日志等级不是越多越好，也不是越少越好。关键是每个等级都有明确的语义和触发条件，大家一看就懂，一查就准。