开篇故事：一个让ECU“卡死”的例程调用
上个月，我帮一家Tier1排查一个棘手的OTA升级问题。他们的ECU在远程刷写后，总会随机出现“死机”——仪表盘黑屏、CAN总线静默，只能断电重启。我拿到log一看，问题出在0x31 RoutineControl服务上。
他们的刷写流程是这样的：先发0x31 01 FF 00（启动例程），然后发0x34请求下载，最后发0x31 02 FF 00（停止例程）。
乍看没问题，但细看时间戳：启动例程后，紧接着发了0x34请求下载，中间间隔仅5ms。结果ECU在处理0x31时，状态机还没完成“启动→运行”的转换，就被0x34打断，导致内部资源泄漏，最终死锁。
这个场景你肯定不陌生——很多工程师以为0x31只是“发个请求、收个响应”那么简单，但实际它的背后是一个有限状态机。状态管理不当，轻则响应超时，重则ECU“假死”。
痛点拆解：三个最常见的“状态机认知误区”
误区1：把例程当成“一次性函数调用”
很多人在实现0x31时，会写这样的伪代码：
// 反例：将例程当作普通函数
void RoutineControl_Handler(
