在前面的几篇文章中，我们已经反复提到一个角色------Radar Header 报文。
它出现的频率甚至高于 Object Data 本身：
- 用它来开启一个感知周期
- 用它来判断 Object List 是否完整
- 用它来做超时、丢帧和复位检测
这自然会引出一个问题：
为什么一帧"不承载任何 Object 数据"的 Header，
反而成了 MCU 感知周期中最关键的报文？
答案在于：
Header 并不是数据报文，而是"语义锚点"。 这里有必要强调下，虽然前文已经提到了相关概念与内容，但是还是很有必要单独开一篇。
1. 没有 Header，MCU 根本不知道"周期"是什么
从 CAN 总线的角度看，所有报文都是平等的：
- 一帧就是一帧
- 顺序可能被打断
- 中间可能丢失
但从感知系统的角度看，情况完全不同。
Radar 的输出不是"一帧一帧的 Object"，而是：
"这是我在某一个时刻，对世界的整体观测结果。"
这个"某一个时刻"，在 MCU 里必须被明确标识，否则就会出现几个根本性问题：
- MCU 无法区分不同感知周期的数据
- Object 数据可能跨周期混用
- Fusion / Tracking 不知道自己处理的是哪一刻的世界
Header 的第一层作用，就是在连续的 CAN 帧流中，给 MCU 插入一个"周期边界"。
2. Radar Header 报文里，真正关键的不是字段数量，而是语义
一个典型的 Radar Header 报文，字段并不复杂：
| 字段 | 表面含义 | 实际工程语义 |
|---|---|---|
| Cycle Counter | 周期编号 | MCU 感知周期锚点 |
| Object Count | Object 数 | MCU 拼装完成条件 |
| Timestamp | 时间戳 | 多传感器对齐依据 |
| Alive Counter | 心跳 | Radar 活性证明 |
| CRC | 校验 | Header 自身可信度 |
这些字段单独看都不复杂，但它们组合在一起，形成了一件非常重要的事情：
Radar 在"声明"本周期的感知结果应当是什么样子。
而 MCU 的职责，不是"生成 Header"，而是：
验证雷达的这份声明是否被完整、正确地接收。
3. Header 是 MCU 拼装 Object List 的"起点条件"
在第三篇中我们已经提到，MCU 内部拼装 Object List 时，核心变量是：
c
current_cycle_id
expected_obj_num
received_obj_num这三个变量，全部在 Header 到达时被初始化。
一个真实的工程时序
MCU Radar MCU Radar Header (cycle=128, obj_cnt=24) current_cycle_id = 128 expected_obj_num = 24 Object Frame Object Frame ... Object Frame
如果没有 Header，MCU 将陷入一个无法解决的困境：
- 不知道什么时候该清空旧数据
- 不知道应该等多少 Object
- 不知道什么时候算"收全了"
因此，在工程上几乎是一个共识：
Object Data 可以延迟、可以丢帧、可以重排，
但 Header 一旦缺失，这个周期基本就失去意义了。
4. 为什么 Header 是"宁可丢，不可错"的判据
在量产系统中，一个很常见、但对新手来说不太直观的设计原则是：
宁可丢掉一个完整感知周期，也不要使用一个不确定周期。
Header 在这里承担的是"裁判"的角色。
常见 Header 异常及 MCU 行为
| Header 异常 | MCU 工程处理 |
|---|---|
| Cycle Counter 跳变 | 丢弃当前周期 |
| Header CRC 错误 | 忽略该 Header |
| Header 超时未到 | Object 不入账 |
| Header 重复 | 保留最新一次 |
特别要强调的是：
MCU 不会因为收到了 Object Data，就"猜测"周期存在。
没有 Header 的 Object 数据，在工程上通常会被视为：
"无锚点数据"，不可被消费。
5. Header 也是功能安全与系统监控的落点
在很多项目中，Alive Counter、Timeout 检测往往被误用在 Object Data 上。
但从工程语义上看，这是不合理的。
为什么 Alive 不适合放在 Object Data？
因为：
- Object Data 是"业务结果"
- Alive 表达的是"系统是否还活着"
Header 才是那个**"周期性必达"的系统级报文**。
MCU 常见监控逻辑
text
如果连续 N 个周期未收到 Header
→ 判定 Radar 异常
→ 通知系统降级而不是：
text
Object 少了几个
→ 勉强继续用Header 的存在，使 MCU 可以在非常早的阶段发现系统级问题，而不是等到算法异常。
6. 一个工程视角的总结
可以用一句话来理解 Radar Header 报文的地位：
Header 不是数据的一部分，
而是 MCU 理解"数据属于哪一次世界观测"的唯一锚点。
它决定了：
- 一个感知周期从哪里开始
- 这个周期应该包含什么
- 这个周期是否可信
- 这个周期是否值得被消费
这也是为什么在很多成熟系统中：
Header 报文的稳定性，比单个 Object 的精度更重要。