4、日志内容规范：时间戳、模块ID、事件ID、数据载荷的标准化格式
日志这东西，看着简单，写起来全是坑。
我见过太多项目，日志倒是打了一堆，结果出了问题根本没法用。时间戳对不上、模块ID乱写、事件ID重复……说白了，日志规范没定好，后面排查问题就是大海捞针。
今天咱们就聊聊，日志内容到底该怎么标准化。我把自己踩过的坑、总结的经验，都摊开来讲。
4.1 时间戳：日志的灵魂
时间戳是日志里最重要的字段，没有之一。你想想看，如果时间戳不准，那整个日志序列就是一堆乱码，根本没法还原现场。
注意：时间戳必须统一使用UTC时间，不要用本地时间。我曾经遇到过一个项目，不同ECU用不同时区的时间戳，结果事故分析时对不上时间线，白白浪费了两周。
我个人习惯用Unix时间戳，精确到毫秒。为什么？因为好计算、好比较、好存储。你想想看，如果存成"2024-01-15 14:30:22.123"，解析起来多麻烦？
标准格式建议：
// 推荐格式：Unix时间戳（毫秒级）
uint64_t timestamp_ms = 1705314622123;
// 或者用结构体
typedef struct {
uint32_t seconds; // Unix秒
uint16_t milliseconds; // 毫秒偏移
} Timestamp_t;小技巧：时间戳的精度要跟系统时钟源匹配。如果用的是晶振，精度到毫秒就够了。别盲目追求微秒级，反而增加开销。
4.2 模块ID：谁打的日志？
模块ID就是日志的"身份证"。你得一眼看出来，这条日志是哪个模块打的。
我建议用分层编码的方式：
| 层级 | 含义 | 示例 |
|---|---|---|
| 域（Domain） | 功能域划分 | 0x01 = 动力域 |
| 子系统（Subsystem） | 子系统编号 | 0x0A = 发动机管理 |
| 模块（Module） | 具体软件模块 | 0x03 = 喷油控制 |
组合起来就是 0x010A03，一眼就能定位到"动力域-发动机管理-喷油控制模块"。
关键点：模块ID必须在项目启动时就定好，不能边写边加。我见过一个项目，模块ID从0x01排到0xFF，结果后面新加的模块没号用了，只能复用旧的……那叫一个乱。
4.3 事件ID：发生了什么？
事件ID描述的是"发生了什么"。它跟模块ID配合，就能精确定位到某个模块的某个事件。
事件ID的编码，我建议按功能分类：
- 0x0000-0x0FFF：初始化/配置事件
- 0x1000-0x1FFF：正常运行事件
- 0x2000-0x2FFF：警告事件
- 0x3000-0x3FFF：错误/故障事件
- 0x4000-0x4FFF：安全相关事件
举个例子：
// 模块ID: 0x010A03 (动力域-发动机管理-喷油控制)
// 事件ID: 0x2001 (喷油压力过高警告)
// 日志内容
[1705314622123] [0x010A03] [0x2001] {pressure: 450, threshold: 400}避坑指南：事件ID不能重复，也不能随意删除。我曾经删过一个旧事件ID，结果新模块用了同样的ID，排查问题时完全搞混了。建议用枚举类型统一管理。
4.4 数据载荷：关键信息不能丢
数据载荷是日志的"肉"，记录了事件发生时的关键数据。但这里有个矛盾：数据越多，排查越方便；数据越多，存储压力越大。
我的建议是：
- 只记录关键变量：别把整个结构体都扔进去。比如喷油压力过高，记录压力值和阈值就够了。
- 用键值对格式：方便解析，也方便扩展。
- 固定长度：每个载荷最大64字节，超了就截断。
标准格式示例：
// 数据载荷格式：{key1: value1, key2: value2, ...}
// 示例1：传感器数据
{speed: 120, rpm: 3500, temp: 95}
// 示例2：故障信息
{code: 0x1234, count: 3, first_occur: 1705314622123}
// 示例3：状态切换
{from: "INIT", to: "RUN", reason: "power_on"}个人经验：数据载荷里一定要加一个"上下文ID"。比如同一个故障连续触发，上下文ID能帮你区分是哪一次。我吃过这个亏，不加上下文ID，根本分不清是第几次触发的。
4.5 完整日志格式示例
把上面这些串起来，一个标准的日志条目长这样：
// 标准日志格式
// [时间戳] [模块ID] [事件ID] {数据载荷}
// 实际例子
[1705314622123] [0x010A03] [0x2001] {pressure: 450, threshold: 400, ctx_id: 0x001A}
// 二进制格式（用于嵌入式存储）
typedef struct {
uint64_t timestamp; // 8字节
uint32_t module_id; // 4字节
uint16_t event_id; // 2字节
uint8_t payload_len; // 1字节
uint8_t payload[64]; // 最大64字节
} LogEntry_t; // 总大小：79字节核心原则：日志格式一旦定下来，就不要轻易改。改格式意味着所有解析工具都要跟着改，成本太高。我建议在项目初期就定好格式，然后写一个日志解析库，后面所有模块都调用同一个库。
4.6 知识体系总览
下面这张图，把日志内容规范的核心逻辑串起来了：
嗯，这张图把咱们刚才讲的内容都串起来了。时间戳、模块ID、事件ID、数据载荷，四个部分缺一不可。
最后说一句：日志规范这东西，看着是小事，但真到出问题的时候，它就是救命稻草。别嫌麻烦，一开始就定好规矩，后面能省你无数时间。