CAN 总线是广播机制 ：发送方不会 "指定接收者"，而是将带有 0x12 ID 的帧广播到整个总线上；
1. 发送时：can_send_msg(0x12, canbuf, sizeof(canbuf))
这里的 0x12 是 发送的 CAN 帧的标识符（ID），代表 "这一帧数据的标识"，而非 "发送到某个目标设备的地址"。
- CAN 总线是广播机制 ：发送方不会 "指定接收者"，而是将带有
0x12ID 的帧广播到整个总线上； - 总线上所有的 CAN 设备都会接收到这一帧，但只会根据自身的 "过滤规则" 决定是否处理该帧（比如只处理 ID 为
0x12的帧）。
简单说：发送时的 0x12 是 "给这帧数据贴的标签"，告诉总线 "这是什么类型 / 标识的数据"。
2. 接收时：rxlen = can_receive_msg(0x12, canbuf)
这里的 0x12 是 接收方要 "监听" 的 CAN 帧标识符（ID） ，即 "只接收总线中 ID 为 0x12 的帧"。
- 接收方会过滤总线上的所有帧，只提取 ID 与
0x12匹配的帧数据，存入canbuf； - 如果总线上有其他 ID（比如
0x13、0x20）的帧，接收方会忽略，不会读取这些帧的数据。
简单说：接收时的 0x12 是 "接收方的监听条件"，只处理 "标签为 0x12 的数据"。
结合代码的完整逻辑（以环回模式为例）
代码中 CAN 初始化默认是 环回模式（LoopBack Mode），此时发送方和接收方是同一个设备（开发板自己发、自己收）：
- 按下 KEY0：发送一帧 ID 为
0x12、数据为[cnt, cnt+1, ..., cnt+7]的 CAN 帧（广播到总线，实际是自己接收）； - 接收函数
can_receive_msg(0x12, canbuf)会监听总线，发现有 ID 为0x12的帧，就将数据读取到canbuf，并在 LCD 上显示。
补充：普通模式（Normal Mode）的逻辑
如果按下 WK_UP 切换到普通模式，需要两个开发板：
- 开发板 A 发送 ID 为
0x12的帧（广播到总线）； - 开发板 B 运行同样的代码，接收时监听 ID
0x12，就会接收到开发板 A 发送的帧； - 若开发板 B 要给 A 回发数据，也需要发送 ID 为
0x12的帧（或双方约定好的其他 ID），A 监听该 ID 即可接收。
问题2：如果同一时刻，有多个设备都发送数据，那么这样岂不是信号乱了
CAN 总线的「仲裁机制」（解决同时发送的冲突）CAN 总线的仲裁逻辑基于 "ID 优先级" ，核心规则可以概括为："谁的 ID 小，谁先发送"（严格来说是 ID 对应的二进制位 "显性电平" 多，优先级更高），且整个仲裁过程是「非破坏性」的（不会损坏已发送的有效数据）。
CAN 总线的仲裁机制、总线电平保护、位同步这些核心 "冲突解决 / 保护机制"，都是由 CAN 控制器硬件（比如 STM32 内置的 bxCAN 外设）自动完成的；
假如同一时刻有标签0x12，0x13，0x14，这三帧数据，那么谁先发送，发送顺序是怎么样的？
0x12 先发送 → 0x13 次之 → 0x14 最后。
CAN 硬件（STM32 的 bxCAN 外设）无论在什么模式下，都严格遵循 CAN 协议，单帧最多只能发送 8 字节