4. Stateflow语义与代码映射

在量产代码开发中，Stateflow 模型最终要落到 C 代码上，而代码生成器并不会“理解”图形，它只是严格按 Stateflow 的语义规则把状态、转移、事件翻译成结构化的 switch/case、if/else 与状态变量赋值。因此，能否预测生成代码的行为，取决于是否真正理解四条语义主线：状态机语义、事件驱动机制、转移优先级、默认转移。本节围绕这四条主线，说明它们与生成代码之间的对应关系。

一、状态机语义：层次、互斥与激活

Stateflow 的状态机语义核心是“层次 + 互斥”。一个父状态被激活时，其内部至多有一个子状态处于激活态（互斥 OR 分解）；若使用并行 AND 分解，则所有子状态同时激活。生成代码中，每个状态对应一个状态变量（如 state_var），激活态用枚举值表示，父状态是否激活由子状态是否激活推导。

例如一个父状态 Run 下含 Idle、Work 两个互斥子状态，生成代码大致为：

switch (state_var) {
  case Run_Idle:
    if (start_evt) { state_var = Run_Work; }
    break;
  case Run_Work:
    if (stop_evt) { state_var = Run_Idle; }
    break;
}

可以看到，层次结构被“扁平化”为带前缀的枚举值，父状态本身不单独占一个 case，而是通过子状态体现。理解这一点，就能解释为什么在 Stateflow 中给父状态写 entry 动作，生成代码会出现在进入任一子状态之前。

二、事件驱动机制：广播、时序与执行顺序

Stateflow 是事件驱动的：状态转移由事件触发，事件分为输入事件、本地事件、输出事件和隐式事件（如 entry、exit、during）。生成代码中，输入事件通常映射为函数入参或全局变量，本地事件在同一个执行步内被“广播”并可能触发级联转移。

关键点在于执行顺序：一个仿真步内，Stateflow 先执行当前激活状态的 during 动作，再按转移优先级评估转移，触发转移时先执行源状态 exit、再执行转移动作、最后执行目标状态 entry。生成代码严格保持这个顺序，因此如果转移动作里修改了某个变量，而 entry 又读取它，结果与图形语义一致。若把逻辑写在 during 里，则它每步都执行，可能造成与预期不同的代码行为。

三、转移优先级：同源多转移的判定顺序

当同一个源状态有多条出转移时，Stateflow 按“从上到下、从左到右”的图形顺序判定优先级，编号越小优先级越高。生成代码中，这些转移被翻译成顺序排列的 if/else if 链，先判定的条件先命中。

例如源状态 S 有两条转移：[a > 0] 在上，[b > 0] 在下。生成代码为：

if (a > 0)      { /* 转移1 */ }
else if (b > 0) { /* 转移2 */ }

若两条条件同时为真，只会走第一条。量产中常见的缺陷是：开发者以为“条件都满足会都执行”，实际只执行最高优先级那条。因此，凡是有互斥语义的转移，应显式写出互斥条件，或调整图形顺序，避免依赖隐式优先级。

四、默认转移：初始激活与复位

默认转移决定父状态首次被激活时进入哪个子状态。它没有触发条件，只有目标。生成代码中，默认转移体现为进入父状态时对状态变量的初始化赋值。若父状态有历史节点（History Junction），则复位时回到上次激活的子状态，生成代码会额外保存“上次子状态”变量。

需要特别注意：默认转移只在父状态首次进入或复位时生效，不会在父状态保持激活期间反复执行。若把初始化逻辑放在默认转移的目标状态 entry 中，则每次进入该子状态都会执行，二者语义不同。

五、把语义映射到代码审查清单

理解了上述对应关系后，在量产代码审查中就可以反向核对：拿到生成代码，检查 switch 的 case 是否与状态层次一致；检查 if/else if 顺序是否与图形转移优先级一致；检查默认转移是否只在进入父状态时赋值；检查 entry、during、exit 动作是否出现在正确位置。下面给出一份可直接使用的核对表。

最后强调一点：Stateflow 的语义是确定性的，代码生成器只是忠实地翻译。只要掌握了状态机语义、事件驱动机制、转移优先级和默认转移这四条主线，就能在模型阶段预判生成代码的结构与行为，从而在量产开发中把一致性验证前移到建模环节，而不是等到代码集成后再去排查语义偏差。