第2章：日志系统基础——日志的作用、日志级别与格式规范
各位同学，咱们今天聊聊日志系统的基础。说实话，我见过太多OTA升级失败的案例，最后查下来，80%的问题都能从日志里找到线索。但前提是——你得会写日志，会看日志。
日志这东西，说白了就是嵌入式系统的「黑匣子」。飞机有黑匣子，咱们的MCU也得有。没有日志的OTA升级，就像闭着眼睛开车，撞了都不知道怎么撞的。
2.1 日志的作用：不只是打印字符串
很多人觉得日志就是printf("hello world")，太肤浅了。我个人的理解，日志在OTA升级中有三个核心作用：
- 状态追踪：升级到哪一步了？下载中？校验中？写入中？每一步都要留痕。
- 异常定位：升级失败了，是网络断了？Flash写坏了？还是固件校验没通过？日志会告诉你答案。
- 性能分析：这次升级花了多久？哪个环节最慢？日志里的时间戳能帮你做优化。
我踩过的坑：有一次量产设备OTA升级失败率高达30%，排查了三天没头绪。最后发现是某批次Flash芯片写入时间比预期长了5倍，导致超时。如果当时日志里没有打印每次写入的耗时，这个Bug可能永远找不到。
你想想看，没有日志的OTA，就像在黑暗里走钢丝。有了日志，至少你知道自己掉在哪了。
2.2 日志级别：DEBUG/INFO/WARN/ERROR
日志级别这东西，很多新手要么全用INFO，要么全用DEBUG。嗯，这里要注意——级别用错了，比不用还糟糕。
我一般把日志分为四个级别，从低到高：
| 级别 | 含义 | OTA场景举例 | 我建议的使用场景 |
|---|---|---|---|
| DEBUG | 调试信息 | 「当前下载进度: 45%」 | 开发阶段、问题复现时开启 |
| INFO | 正常流程 | 「OTA升级开始，版本v1.2→v2.0」 | 正式版本默认开启 |
| WARN | 警告 | 「Flash写入重试第2次」 | 不影响主流程但值得关注 |
| ERROR | 错误 | 「固件校验失败，CRC不匹配」 | 必须记录，触发告警 |
我的习惯：正式发布的固件，只开INFO及以上级别。DEBUG日志会拖慢速度，而且占用Flash空间。但我会在代码里留一个「调试模式」的开关，现场出问题时可以通过特殊指令打开DEBUG级别。
为什么会这样分级？说白了，就是信息过滤。你总不想在几万行日志里找一条ERROR吧？
2.3 日志格式规范：统一就是力量
我记得刚入行那会儿，团队里每个人写日志的格式都不一样。有人用逗号分隔，有人用空格，有人连时间戳都不加。结果每次排查问题，光解析日志就要花半小时。
后来我定了一个规矩，所有日志必须遵循以下格式：
[时间戳] [级别] [模块] [文件名:行号] 日志内容举个例子：
[2024-01-15 14:30:22.456] [INFO] [OTA] [ota_download.c:128] 开始下载固件包，大小: 1048576 bytes
[2024-01-15 14:30:25.123] [WARN] [OTA] [ota_flash.c:56] Flash写入重试，扇区: 0x1000
[2024-01-15 14:30:30.001] [ERROR] [OTA] [ota_verify.c:89] CRC校验失败，期望: 0xA5B6C7D8，实际: 0x12345678每个字段的含义：
- 时间戳：精确到毫秒，方便分析时序问题
- 级别：一目了然知道严重程度
- 模块：快速定位是哪个子系统出的问题
- 文件名:行号：不用去翻代码就能知道是哪一行打印的
- 日志内容：关键信息，尽量包含上下文
我曾经犯过的错：有一次日志里只写了「写入失败」，没有写哪个扇区、什么原因。结果排查时不得不把整个Flash内容读出来对比，浪费了整整两天。从那以后，我要求所有ERROR日志必须附带足够多的上下文信息。
2.4 实战建议：日志系统的设计要点
最后，分享几个我在项目中积累的经验：
- 日志缓冲区要够大：OTA升级过程中可能产生大量日志，缓冲区太小会导致日志丢失。我一般预留至少4KB的环形缓冲区。
- 分级过滤要灵活：运行时可以动态调整日志级别，方便现场调试。
- 日志要持久化：升级失败后设备可能重启，日志要保存到非易失存储中，否则重启后啥也看不到。
- 别在中断里打日志：这个老生常谈了，但总有人犯。中断里打日志轻则影响实时性，重则导致死锁。
好了，日志系统的基础就讲到这里。下一章咱们聊聊OTA升级中常见的日志分析场景，到时候我会拿几个真实案例出来，带大家一步步分析。