Toyota 失控加速案：源码里的“意大利面条”，让陪审团信了软件会让车自己加速？
目录
配图：AI 生成的概念示意图，非真实现场、产品界面或实验数据。
TL;DR：2013 年，美国俄克拉荷马州一场 Toyota 失控加速诉讼里，原告方专家审查了 Camry 的电子节气门源码，称其充满全局变量、违反大量编码规范，并给出一条软件可能导致失控加速的故障路径。陪审团据此认定 Toyota“罪责重大”。但需要说清楚：这是原告专家的证词与陪审团裁决，并不等于法庭或监管机构最终证明了这起事故的确切原因。
这是 2013 年的旧案
事情发生在 2007 年 9 月：俄克拉荷马州一辆 2005 款 Camry 在高速出口匝道上失控加速，撞车后乘客 Barbara Schwarz 死亡，驾驶员 Jean Bookout 重伤。2013 年 10 月，该案在俄克拉荷马州开庭审理，案名 Bookout and Schwarz v. Toyota。这不是新闻，而是一桩如今仍常被软件工程师拿来当教材的老案子。
专家说了什么
原告方请来嵌入式软件专家 Michael Barr，他在安全的房间里花了二十多个月审查 Toyota 的源码，最后出具了数百页报告并出庭作证。另一位专家 Phillip Koopman 则作证说，学界对全局变量的标准是“零”，而这套代码里有一万多个。
Barr 的核心指控大致有这些：
- 代码结构混乱，被他形容为“意大利面条”：部分函数复杂到无法测试、无法维护。
- 违反编码规范的数量惊人：NASA 对部分代码按 35 条 MISRA-C 规则检查，发现 7134 处违规；Barr 按 2004 版规范检查，数出 81514 处。
- 栈保护不足：他认为栈溢出有可能破坏关键数据，让负责节气门的任务悄悄“死掉”。
- 监控形同虚设：看门狗监督程序无法发现大任务的死亡，操作系统返回的错误码还被直接丢弃。
按他的推演，一个控制节气门、定速巡航和多项故障保护的“大杂烩”任务一旦挂掉，节气门可能卡在开启状态。他认为这比驾驶员误踩油门更可能是这起事故的成因。
争议在哪
这套说法并非没有反对声音。Toyota 一直主张是驾驶员操作问题；外部工程师 David Cummings 也在 IEEE 文章中指出，原告方的事故理论在技术上站不住脚。他同时说明自己没看过 Toyota 的源码，对代码质量不置评。系统安全领域也有人评论，庭审证据对软件批评很重，也找到了可能的故障路径，但没有直接把这些路径与本案事故挂钩。原告律师则说，裁决部分依据的是现场长达约 45 米（150 英尺）的刹车痕。
另外，上述大量指控来自付费专家证词，NASA 当年也受限于时间和源码访问范围，并未获得完整代码。
后果
陪审团认定 Toyota 存在“罪责重大”（reckless disregard），判赔共 300 万美元，赔偿金由两位原告各得一半。在陪审团裁定惩罚性赔偿之前，Toyota 与原告达成和解，同时和解了许多类似案件，所以这套证据没有经过上诉检验。
它的意义不在于“证明了软件杀人”，而在于：当安全相关的软件几乎无法被外界审查时，法庭成了少数能强制打开源码的地方；一旦打开，里面的样子足以让陪审团不再相信“绝不可能是软件”。
来源：