一、传统 FSM 的'三宗罪'
几乎所有的 C/C++ 程序员都写过这样的状态机：
enum class RobotState { IDLE, CALIBRATING, MOVING, ERROR };
RobotState currentState = RobotState::IDLE;
// 潜在风险
void updateLogic() {
switch (currentState) {
case RobotState::IDLE: // do something...
break;
case RobotState::CALIBRATING: // do something...
break;
// 问题 1：假如这里漏写了 MOVING 的 case，编译器顶多给个警告，程序照跑不误！
case RobotState::ERROR: // do something...
break;
}
}
传统设计的致命伤：
- 静默失败：当你新增了一个状态（比如
HOMING），你必须在全工程搜索所有的switch并手动添加case。漏掉一个，就是隐藏的线上 Bug。 - 数据耦合（全局变量爆炸）：处于
MOVING状态时，系统需要记录'目标坐标'；处于ERROR状态时，系统需要记录'错误码'。在传统模式下，为了让所有状态都能访问这些数据，你不得不把它们全部定义为庞大的全局变量或类成员，导致极度浪费和耦合。 - 非法转换：没有任何机制能阻止你写出
if (error) currentState = RobotState::CALIBRATING;这种违背物理常理的代码。
二、设计思路：让状态成为'类型' (Type-Driven Design)
在现代 C++ (C++17 及以上) 的哲学中，状态不应该是一个枚举值，而应该是一个独立的'类型 (Class/Struct)'。
我们为每一个状态单独定义一个轻量级的结构体。更绝妙的是，只有在这个状态下才需要的数据，就包裹在这个状态自己的结构体里！
// 1. 定义独立的状态类型，自带专属数据！
struct IdleState {};
struct CalibratingState { int retry_count = 0; // 只有标定状态才需要记录重试次数 };
struct MovingState { float target_x, target_y, target_z; // 只有运动状态才持有目标坐标！ };
struct ErrorState { int error_code; std::string error_message; // 只有错误状态才带有错误信息 };
三、std::variant：类型安全的'超级联合体'
现在有了四个不同的状态类型，我们如何用一个变量来表示'当前状态'？ 不要用基类指针和虚函数（那涉及动态内存分配 new/delete，在嵌入式里是大忌）。
我们要用 C++17 的 std::variant。
#include <variant>
// 状态机变量：它在任何时刻，只能是这四种类型中的【某一种】
using State = std::variant<IdleState, CalibratingState, MovingState, ErrorState>;
// 初始化，默认为 variant 列表里的第一个类型（IdleState）
State currentState = IdleState{};
底层原理： std::variant 在底层其实是一个安全的 union 加上一个类型标签（Tag）。它的内存大小只等于最大的那个状态类型的大小（加上一点对齐开销），完全没有堆内存分配，极度契合 RAM 紧缺的单片机！
四、编译器的严格检查：std::visit 与模式匹配
现在状态变成了类型，我们怎么写 updateLogic()？ 答案是引入 C++17 的核心魔法：std::visit 和 泛型 Lambda (Overloaded Pattern)。
我们要强迫编译器在编译阶段帮我们检查是否处理了所有状态。
// 这是一个 C++17 的经典模板，用于组合多个 Lambda 表达式
template<class... Ts> struct overloaded : Ts... { using Ts::operator()...; };
template<class... Ts> overloaded(Ts...) -> overloaded<Ts...>;
void updateLogic(State& state) {
// std::visit 会根据 state 当前的真实类型，自动路由到对应的 lambda 分支！
std::visit(overloaded {
[&](IdleState& s) {
// 闲置逻辑...
// 发生事件，转移到标定状态
state = CalibratingState{0};
},
[&](CalibratingState& s) {
s.retry_count++;
// 直接访问专属数据！绝对安全！
if (s.retry_count > 3) {
// 标定失败，切换到错误状态，并顺便把错误码塞进去
state = ErrorState{404, "Camera not found"};
} else {
state = MovingState{100.0f, 200.0f, 50.0f};
}
},
[&](MovingState& s) {
// 运动逻辑，直接读取 s.target_x
},
[&](ErrorState& s) {
// 报错逻辑，直接读取 s.error_message
}
}, state);
}
为什么这被称为'类型安全'？ 假设明天，项目经理要求加一个 EmergencyStopState（急停状态）。 你在 std::variant 的定义里加上了它，但忘记在 std::visit 的处理逻辑里写对应的 Lambda 分支。 此时，你点击编译。 编译器会直接报错，拒绝编译通过！ 错误信息会明确告诉你：std::visit 缺失了对 EmergencyStopState 的处理。
你把一个原本可能导致机械臂失控撞毁的运行时 Bug，变成了一个根本无法生成固件的编译期 Error。这就是高级架构师的价值。
五、结语：让状态机拥有'记忆'与'边界'
传统的 FSM 是一张扁平的网，数据和逻辑是分离的。 而在现代 C++ 的 variant/visit 体系下，状态本身成为了承载数据的容器。
- 当系统离开
MovingState时，目标坐标的内存被自动覆盖。 - 当系统进入
ErrorState时，错误码被强制要求初始化传入。 - 任何企图在
IdleState下访问'目标坐标'的代码，在编译时就会被无情拦截，因为IdleState的结构体里压根没有这个变量！
没有全局变量的污染，没有无尽的 switch-case，没有遗漏处理的静默崩溃。C++ 编译器化身为最严苛的质检员，死死捍卫着你设备的逻辑边界。