2. Stateflow工程环境搭建

Stateflow 本身不是一个可以独立安装运行的工具，它依附于 MATLAB 与 Simulink 的版本体系。因此“环境搭建”这件事，本质上是在确定一套可复现、可协作、可追溯的工具链基线：用哪个 MATLAB 版本、模型文件放在哪里、依赖库如何被找到、Simulink 配置参数如何统一、以及这些内容如何进入 Git 等版本管理系统。这一节按这条主线展开，并给出可直接落地的目录与配置样例。

一、版本选型：先定基线，再谈兼容

Stateflow 的语法、代码生成行为、以及与 Simulink 的集成方式会随版本变化。选型时优先考虑三个约束：目标代码生成工具链（如 Embedded Coder 的目标编译器）、团队已有授权、以及项目生命周期内的升级成本。工程实践中通常选择“当前主流 Release 的较新 Update 版本”，例如 R2021b Update 6、R2022b Update 4 这类带 Update 的版本，因为它们修复了该 Release 早期的问题，同时避免使用刚发布的 .0 版本。

需要特别注意的是：同一项目内所有成员必须使用完全一致的 MATLAB 版本号（含 Update 号）。R2022b 与 R2022b Update 3 在模型升级、缓存格式上可能存在差异，混用会导致模型被静默升级，回退困难。建议在项目根目录放置一份 toolchain.md 或 README，明确记录：MATLAB 版本、Simulink 版本、Stateflow 版本、Embedded Coder 版本、编译器版本（如 MinGW-w64 8.1 或 Visual Studio 2019）。

二、项目目录规范：让模型、脚本、数据各归其位

Stateflow 工程常见的混乱来源是：模型文件、初始化脚本、数据字典、生成代码、测试用例混在同一层目录。推荐采用如下结构（以项目名 MotorCtrl 为例）：

MotorCtrl/
├─ model/                # .slx 模型与 Stateflow 图表
│   ├─ MotorCtrl_top.slx
│   └─ lib/              # 项目内复用库
├─ data/                 # 数据字典、参数 .m/.mat
│   ├─ MotorCtrl.sldd
│   └─ params_init.m
├─ script/               # 初始化、构建、检查脚本
│   ├─ setup_path.m
│   └─ build_model.m
├─ test/                 # 测试用例与测试管理器
├─ generated/            # 生成代码（不纳入版本管理）
├─ doc/                  # 需求、设计说明
└─ toolchain.md          # 版本基线记录

其中 generated/ 应写入 .gitignore，因为生成代码可由模型重建，纳入版本管理会造成大量无意义 diff。而 model/、data/、script/、test/ 必须纳入版本管理。

三、模型库路径：用脚本统一，而非手动 addpath

Stateflow 图表中引用的库、数据字典、以及自定义的 sfun 或 MATLAB Function 依赖，都需要在 MATLAB 路径中可见。手动 addpath 不可复现，正确做法是编写 setup_path.m，在每次打开工程时执行：

function setup_path()
    root = fileparts(mfilename('fullpath'));
    root = fileparts(root);          % 回到项目根
    addpath(fullfile(root,'model'));
    addpath(fullfile(root,'model','lib'));
    addpath(fullfile(root,'script'));
    addpath(fullfile(root,'data'));
    % 绑定数据字典
    Simulink.data.dictionary.open('MotorCtrl.sldd');
end

更规范的方式是使用 Simulink Project（.prj），把路径、启动脚本、数据字典、快捷方式全部封装进工程，成员打开 .prj 即自动完成环境初始化。对于 Stateflow 而言，这能避免“图表能打开但引用的数据字典找不到”这类典型问题。

四、配置参数：Configuration Parameters 的统一

Stateflow 的行为受 Simulink 配置参数强烈影响，尤其是求解器、代码生成、以及 Stateflow 专属选项。建议把配置参数保存为 Simulink.ConfigSet 对象，在初始化脚本中统一加载，而不是每个模型手动设置。关键参数示例：

加载方式：setActiveConfigSet('MotorCtrl_top','MotorCtrl_cfg')，其中 MotorCtrl_cfg 由 params_init.m 生成。这样任何成员打开模型，配置都一致。

五、版本管理集成：模型 diff 与锁定

Simulink 模型是二进制 .slx，Git 默认无法 diff。工程上通常采用两种策略：一是使用 MATLAB 自带的 slx 与 Git 集成（通过 Simulink Project 的版本控制接口），二是导出为 .xml 或 .m 进行文本化比较。对于 Stateflow，更实用的做法是：把状态机的核心逻辑用 MATLAB Function 或外部 .m 脚本表达，模型只保留结构，从而让逻辑部分可 diff。

此外，.slx 文件应设置为 Git LFS 管理，避免仓库膨胀。数据字典 .sldd 同样建议 LFS。提交前运行 build_model.m 做一次模型检查（modeladvisor），确保没有未保存的改动或路径错误。

六、落地检查清单

完成上述五步后，用以下清单自检，全部通过才算环境搭建完成：

• 项目根目录存在 toolchain.md，记录 MATLAB 版本（含 Update）、编译器版本。
• setup_path.m 可在任意工作目录下正确执行，无硬编码绝对路径。
• 数据字典 .sldd 已绑定，Stateflow 图表中引用的参数无“未定义”警告。
• 配置参数由 ConfigSet 统一加载，模型打开后求解器与代码生成设置一致。
• .slx 与 .sldd 已纳入 Git LFS，generated/ 已忽略。
• 新成员克隆仓库后，仅需打开 .prj 或运行 setup_path.m，即可编译通过。

这套环境一旦建立，后续所有 Stateflow 建模、代码生成、测试与交付都在这条基线上进行，避免因版本漂移或路径混乱导致的返工。