企业官网建设流程全解析

我第一次认真把状态模式在 C++ 里落地，不是在看设计模式书的时候，而是在做一个自动空调控制相关项目，遇到了一份类似 u280187 的报文。这份报文把空调控制状态、设定温度、空气循环模式都放进了一段数据里，程序每收到一帧，就要根据当前模式决定界面怎么显示、后续控制报文怎么发、用户按键怎么响应。初版代码我图省事，全用 bool 标志位加 if-else 拼，结果每次新增一个模式和一组交互规则，都要改十几个分支，漏改一处就是 bug。后来我把这堆逻辑重构成状态模式，才发现这个模式在 C++ 里比在其它语言里更容易踩坑，也更容易被用错。

这篇文章适合三种人看：第一种是写过 if-else 状态机但觉得维护困难的 C++ 开发者；第二种是想搞懂状态模式到底怎么在 C++ 里安全落地，尤其是状态对象生命周期怎么管理的读者；第三种是正在做设备控制、报文解析、上位机状态同步这类项目，想把逻辑整理清楚的人。我会把多态实现、std::variant 实现、表驱动状态机三种路子都写一遍，再补充真实项目里的调试经验，尽量让新手看完能直接抄，老手看了也能挑出点自己想验证的细节。

1. 为什么状态模式是 C++ 里最容易被误解的设计模式

1.1 状态模式到底解决了什么问题

很多文章喜欢把状态模式描述成“当一个对象的行为取决于它的状态，并且运行时需要根据状态改变行为”时使用的模式。这话没错，但太抽象了。我换个说法：状态模式让你把“现在处于什么模式”和“在这个模式下应该怎么反应”这两件事，从一团 if-else 里拆出来，拆成一组互相独立的类。

最典型的反面例子是这样的：代码里写着is_auto_mode_、is_cooling_、is_heating_、is_fan_only_四个布尔量，每次按键都先判断这些布尔量，再决定调用哪段逻辑。刚开始只有开机、关机两个状态还好，但一旦出现“自动模式按模式键切换到制冷”“制冷模式按模式键切换到加热”“加热模式按模式键切换到仅送风”这种规则，布尔量之间就产生了组合爆炸。你不仅要保证每次切换时把旧布尔量清掉、新布尔量置位，还要在几十处判断里保持一致，这几乎必然出错。

状态模式把每个模式变成一个具体类，让模式和模式之间的转换规则落在类的方法里。这样做的核心价值不是“少写代码”，而是“让逻辑有明确归属”。每个状态类只知道自己能响应哪些事件、要跳转到哪、跳转时要不要更新参数；上下文对象只负责保存当前状态、触发事件、以及提供状态需要访问的数据。新增一个模式，不再是到处改 if-else，而是新增一个具体状态类，然后确定它的事件处理逻辑。

1.2 状态模式与状态机不是一回事

这两个概念经常被混在一起，但严格来说不是同一层的东西。状态机是一个更宽泛的模型，它描述的是“状态、事件、转移、动作”的集合；而状态模式是一种代码组织方式，它借用了“状态”这个抽象概念，用类和多态来承载状态相关的行为。

我见过不少团队把这两者搞混，导致项目里出现一种很尴尬的写法：先写一个 State 基类，然后派生二十个子类，每个子类里只有一个 Switch 语句，内容是根据事件类型判断要不要转换。这本质上还是状态机，只是把状态拆成了二十个类。反而增加了阅读成本。

正确的关系是互补的：如果你把“当前状态”抽象成对象，那就用状态模式来处理该状态下的事件；如果你更看重“状态的转移表”，关心的是从哪个状态经过哪个事件到哪个状态，那就用表驱动状态机。很多实际项目是两者结合：用表来定义转移关系，用状态对象来承载状态进入、退出和停留时的具体动作。

所以别一上来就执着于“这到底是状态模式还是状态机”，先想清楚你手头的问题更依赖哪一面：是行为差异大、必须通过多态区分，还是转移关系复杂、需要集中审查。想清楚了，再去选实现方式。

2. 经典多态实现：状态类、上下文和虚函数

2.1 三个角色的职责划分

经典的状态模式有三个角色：上下文（Context）、状态接口（State）和具体状态（ConcreteState）。在空调控制的例子里，AirConditioner 是上下文，State 是状态接口，OffState、AutoState 这些就是具体状态。

上下文的职责有三个：保存当前状态、对外提供事件入口、向状态暴露内部数据。状态接口的职责是定义一组虚函数，每个虚函数对应一种可触发的事件。具体状态则实现这些虚函数，决定自己在收到事件时执行什么动作、是否切换到另一个状态。

这个三角关系里最容易犯错的是依赖方向。状态类在处理事件时通常需要访问上下文中的数据，比如空调当前的温度、循环模式，所以状态方法要接收一个AirConditioner&引用。而状态类要切换状态，又得调用上下文的setState。于是状态和上下文互相引用。这是合理的，但如果你不注意生命周期，就会变成灾难。

另外，状态接口的事件定义要仔细斟酌。常见的做法是按业务动作命名，比如onPower、onModeChange、onTemperatureUp。如果以后新增一个事件，比如“遥控器学习码”，你就得在 State 基类里加一个纯虚函数，所有具体状态类都要改。这也是多态状态模式的痛点之一，后面会再说。

2.2 一个最小可编译的空调控制示例

我直接写一个能编译的最小例子，状态只做四件事：开机、关机、切换模式、调节温度、切换内外循环。为了让示例不拖泥带水，我统一用静态单例状态对象，避免先引入内存管理问题。

先定义事件枚举和状态基类：

#include <iostream> enum class Event { Power, Mode, AdjustUp, AdjustDown, ToggleAirCycle }; class AirConditioner; class State { public: virtual ~State() = default; virtual void onPower(AirConditioner& ac) = 0; virtual void onMode(AirConditioner& ac) = 0; virtual void onAdjustUp(AirConditioner& ac) = 0; virtual void onAdjustDown(AirConditioner& ac) = 0; virtual void onToggleAirCycle(AirConditioner& ac) = 0; };

然后是上下文 AirConditioner。它持有当前状态指针、当前温度和内外循环标志，setState负责切换状态，handleEvent把事件转发给当前状态：

class AirConditioner { public: AirConditioner() : state_(&OffState::instance()), temperature_(26), internalAirCycle_(true) {} void setState(State& next) { state_ = &next; std::cout << "state changed\n"; } void handleEvent(Event ev) { State& cur = *state_; switch (ev) { case Event::Power: cur.onPower(*this); break; case Event::Mode: cur.onMode(*this); break; case Event::AdjustUp: cur.onAdjustUp(*this); break; case Event::AdjustDown: cur.onAdjustDown(*this); break; case Event::ToggleAirCycle: cur.onToggleAirCycle(*this); break; } } int temperature() const { return temperature_; } void setTemperature(int t) { temperature_ = t; } bool internalAirCycle() const { return internalAirCycle_; } void setInternalAirCycle(bool v) { internalAirCycle_ = v; } private: State* state_; int temperature_; bool internalAirCycle_; };

注意handleEvent里我先把当前状态引用取出来，再做分支转发。这么做是有原因的：如果在状态处理过程中调用了setState，你仍然安全地完成了本次事件转发，不会出现“状态已经切换，但线程还在处理旧状态方法”的边界问题。单例状态对象不会被删除，所以这个写法在生命周期上是安全的。

具体状态类我展示三个比较有代表性的。先看 OffState：

class OffState : public State { public: static OffState& instance() { static OffState s; return s; } void onPower(AirConditioner& ac) override { ac.setState(AutoState::instance()); } void onMode(AirConditioner& ac) override {} void onAdjustUp(AirConditioner& ac) override {} void onAdjustDown(AirConditioner& ac) override {} void onToggleAirCycle(AirConditioner& ac) override {} };

关机状态下除了开机键，其他事件全部忽略。AutoState 是最常见的工作模式：

class AutoState : public State { public: static AutoState& instance() { static AutoState s; return s; } void onPower(AirConditioner& ac) override { ac.setState(OffState::instance()); } void onMode(AirConditioner& ac) override { ac.setState(CoolingState::instance()); } void onAdjustUp(AirConditioner& ac) override { ac.setTemperature(ac.temperature() + 1); } void onAdjustDown(AirConditioner& ac) override { ac.setTemperature(ac.temperature() - 1); } void onToggleAirCycle(AirConditioner& ac) override { ac.setInternalAirCycle(!ac.internalAirCycle()); } };

制冷态、加热态、仅送风态的代码结构完全一样，只是切换目标不同。比如 CoolingState 的onMode切换到 HeatingState，HeatingState 的onMode切换到 FanOnlyState，FanOnlyState 的onMode再切回 AutoState。

这套代码的好处是把“模式切换规则”固化在具体状态里。以后想加一个“除湿模式”，就新增 DehumidifyState，再决定从哪些状态可以进入、按模式键从除湿模式跳到哪个状态。原有的 AutoState、CoolingState 只需改一行跳转目标，不用动全部逻辑。

2.3 状态切换的三种写法与生命周期陷阱

状态切换的写法直接影响代码安全性和可维护性，这里单独展开讲。

第一种写法是我上面示例里的方式：状态对象全部是无状态单例，切换状态时直接setState(SomeState::instance())。这种方式最省心，内存零分配，线程安全也容易保证，因为状态类本身没有可变成员。前提是你的状态不需要保存自己的数据，比如 AutoState 不需要记录“当前自动模式目标温度”，因为这类数据放在上下文里更合适。

第二种写法是每个状态内部new一个目标状态并传给setState，比如ac.setState(new CoolingState())。这就是隐患最大的一种。如果上下文用State*接收且不负责删除，那就是内存泄漏；如果上下文用std::unique_ptr接管，又会遇到那个经典问题：当前状态对象在处理事件时调用setState，unique_ptr赋值会立刻销毁正在执行方法的this对象，方法还没返回，对象已经被析构。虽然有些写法碰巧不出错，但这是踩在未定义行为的边缘上，我不会在真实项目里这么写。

第三种写法是把状态切换规则上移到上下文或专门的转移表中，状态类只负责具体动作。比如handleEvent内部先由当前状态和事件查表得到目标状态，再调用当前状态的onExit、目标状态的onEnter。这种写法已经偏向状态机，但能避免状态类之间互相引用，也让转移规则可以整体预览。如果项目里状态多、转换规则频繁变动，我推荐这种。

提醒：只要状态处理函数里可能触发状态切换，就不要让状态对象拥有复杂内部资源，更不要让状态对象把自己的堆内存控件交给上下文管理。最稳妥的组合是“状态单例 + 上下文保存状态指针 + 转换规则在独立函数或转移表中”。

3. 现代 C++ 实现变体：从 std::variant 到表驱动

3.1 多态实现的四个现实问题

多态状态模式在示例里很好看，但落到实际工程里会陆续冒出一堆问题。

第一个问题是状态类的数量膨胀。空调这么简单的业务，四个模式加一个关机就是五个状态，每个状态要覆写至少五个虚函数，文件数量一下增加很多。如果某个状态对某个事件没有响应，你也得写一个空函数填在那里。代码行数可能不比 if-else 少，只是逻辑更分散。

第二个问题是状态内部数据的存储。很多真实状态不是“存在即可”，而是有参数的。比如制冷模式下有目标温度，仅送风模式有风速档位。如果你用单例状态，这些参数只能放在上下文里；如果你让每个状态持有参数，就需要为每个实例单独创建状态对象，生命周期又变复杂。

第三个问题是虚函数分派不是免费的。单次虚调用开销很小，但如果状态流转频繁，每秒处理几千上万个事件，每次事件又可能触发好多次虚调用，分配和缓存命中率都会变成可测量的成本。对嵌入式或低功耗设备尤其明显。

第四个问题是扩展方向受限。新增具体状态类很容易，但新增一个事件类型就很麻烦，因为 State 基类和所有具体类都要加一个虚函数。这就是所谓“表达式问题”：多态擅长增加类型，不擅长增加操作。事件类型的增加频率如果比状态类型的增加频率还高，就要考虑别的实现。

3.2 用 std::variant 保存状态

C++17 给状态模式提供了一个很有吸引力的替代实现：把状态放进std::variant，用访问器模式来处理事件。这种做法不再需要虚函数，也不需要把状态类组织成继承体系，状态之间是平行的普通结构体。

用一个简化版空调来演示。先定义状态类型：

#include <variant> struct OffState {}; struct AutoState {}; struct CoolingState {}; struct HeatingState {}; struct FanOnlyState {}; using AcMode = std::variant<OffState, AutoState, CoolingState, HeatingState, FanOnlyState>;

AirConditioner 里不再有State*，直接保存一个AcMode：

class AirConditioner { public: AcMode mode; int temperature = 26; bool internalCycle = true; void setMode(AcMode m) { mode = std::move(m); } void handleEvent(Event ev); };

事件处理的入口使用std::visit和 Overload 模式：

template<typename... Ts> struct Overload : Ts... { using Ts::operator()...; }; template<typename... Ts> Overload(Ts...) -> Overload<Ts...>; void AirConditioner::handleEvent(Event ev) { std::visit(Overload{ [&](OffState&) { if (ev == Event::Power) { setMode(AutoState{}); } }, [&](AutoState&) { switch (ev) { case Event::Power: setMode(OffState{}); break; case Event::Mode: setMode(CoolingState{}); break; case Event::AdjustUp: temperature++; break; case Event::AdjustDown: temperature--; break; case Event::ToggleAirCycle: internalCycle = !internalCycle; break; } }, [&](CoolingState&) { switch (ev) { case Event::Power: setMode(OffState{}); break; case Event::Mode: setMode(HeatingState{}); break; case Event::AdjustUp: temperature++; break; case Event::AdjustDown: temperature--; break; case Event::ToggleAirCycle: internalCycle = !internalCycle; break; } }, [&](HeatingState&) { // 类似 }, [&](FanOnlyState&) { // 类似 } }, mode); }

这套写法的优点非常明显：状态对象就是普通值类型，没有堆分配，没有虚函数调用，缓存友好；所有状态类型在编译期可见，如果某个事件在某状态下没有处理分支，你也不容易漏掉，因为代码一目了然；新增一个状态只需要加一个结构体，然后扩展 Overload 里的 lambda，编译期就能检查所有std::visit的调用点。

缺点也明显：Overload 模式写起来有不少模板样板；如果状态很多，一个handleEvent里的 lambda 列表会很长；某些编译器版本对折叠表达式和推导指引支持不完整，会报出很晦涩的错误。另外，如果一个状态本身就带参数，variant 里该结构体就需要持有对应的字段，这反而让数据结构更紧凑，是优点。

我在实际项目里遇到“状态数量小于十个、事件数量也不多”的情形，会优先用 variant 而不是多态。因为它把状态切换、事件处理和上下文数据的关系压缩在极少代码里，便于审查。

3.3 表驱动状态机：什么时候值得用

另一种常见实现是表驱动。它不直接对应 GoF 状态模式，但经常和状态模式同场出现，尤其适合报文解析、通信协议这类“外部事件驱动”的场景。

核心思路是定义状态枚举、事件枚举，以及一张转移表：

enum class AcState { Off, Auto, Cooling, Heating, FanOnly }; enum class Event { Power, Mode, AdjustUp, AdjustDown, ToggleCycle }; struct Transition { AcState from; Event event; AcState to; void (*action)(AirConditioner&); }; const Transition kTransitions[] = { {AcState::Off, Event::Power, AcState::Auto, EnterAuto}, {AcState::Auto, Event::Power, AcState::Off, ExitWork}, {AcState::Auto, Event::Mode, AcState::Cooling, EnterCooling}, {AcState::Cooling, Event::Mode, AcState::Heating, EnterHeating}, {AcState::Heating, Event::Mode, AcState::FanOnly, EnterFanOnly}, {AcState::FanOnly, Event::Mode, AcState::Auto, EnterAuto}, // 温度调节、循环切换可以继续追加 };

handleEvent只需要遍历表，找到匹配的转换，执行动作，更新当前状态。查找可以是线性扫描，也可以根据状态和事件建立哈希映射。

表驱动的最大价值是可审查性。你把整张转换表摊开，一眼就能看出“从哪个状态、遇到哪个事件、跳到哪个状态”。这对协议实现、设备控制等需要安全审查的模块非常友好。而且新增一种跳转规则不需要动任何状态类，只需要在表里加一行。

但它也有自己的问题：一旦需要“带条件的跳转”，比如“温度超过 30 度才进入制冷”，单纯的四列表就写不清楚，需要加 guard 条件列。一张表如果塞满 guard、action、enter、exit 回调，复杂度会快速上升。表驱动还容易导致事件类型和状态类型都被抽象成枚举，业务逻辑全部塞进回调函数，最后变成一个弱类型的“小脚本引擎”。

所以我的判断是：状态间转移规则多而复杂、事件源头单一、需要集中评审的场景用表驱动；状态行为差异大、事件处理逻辑重、编译期安全性要求高的场景用 std::variant 或多态。

3.4 三套方案怎么选

我用一张表总结一下选型思路，方便你对照实际项目判断：

如果你是一个小团队要维护一个长期项目，我倾向于 default 用 std::variant，因为它最符合 C++ 的值语义习惯，调试起来直接看当前 mode 值是什么就行。只有当状态类之间职责差异足够大、需要新增状态时，才考虑多态。表驱动则更像是一张“转移地图”，适合在需求阶段先画出来，再决定用哪种代码形态承载。

4. 实际项目落地：自动空调报文解析状态机

4.1 报文里的状态字段如何映射为事件

前面提到的 u280187 报文，我简化成下面这样的结构来讨论：报文的载荷里包含一个模式字段、一个温度字段、一个循环字段。收到后先按协议解析成结构体，再根据字段内容生成事件。

struct AcMessage { uint8_t mode_raw; int16_t target_temperature; uint8_t cycle_flag; uint8_t checksum; };

最常见的错误是解析完报文以后，直接按照mode_raw去改界面和控制逻辑，和内部状态机脱节。比如你画面上显示自动模式，但状态机的当前状态还是关机态，后面用户按了一个键，状态机按关机态处理，界面和实际行为就出现了分歧。

正确做法分两步：第一步，把mode_raw合法性校验掉，将合法字段转成一个语义明确的事件，比如Event::Mode或自定义的Event::ReportMode；第二步，把事件投递给状态机，由状态机决定当前状态下是否接受、是否需要转换。也就是说，报文只是“外部输入”，它产生事件，但不直接决定状态。状态机的当前状态才是行为的唯一权威。

我之前重构的时候，就在报文解析和状态机之间加了一层很薄的映射函数：

Event messageToEvent(const AcMessage& msg) { if (!validate(msg)) { return Event::ProtocolError; } // 省略字段到事件的转换细节 return decodedEvent; }

这层映射有两个作用：一是把协议格式和业务逻辑解耦，未来换协议版本时状态机不用动；二是给报文解析加了一个过滤点，非法报文不会污染状态机。

4.2 消息并发与数据分离

设备控制项目里，报文接收线程和处理线程通常不是同一个。如果让接收线程直接调用状态机的handleEvent，状态机内部就要加锁，而且状态转换可能触发 UI 刷新、控制命令发送，容易造成跨线程的资源竞争。

我的习惯是：接收线程只更新一个受std::mutex保护的最新报文缓存，或者把报文放入队列；处理线程定时拉取最新状态，合成为事件后驱动状态机。这样状态机始终只在单个线程里运行，状态对象不需要考虑多线程安全。可能有人觉得这样延迟高，但对空调控制这种毫秒级实时性要求完全够用。如果对实时性要求更高，可以用无锁队列，但逻辑复杂度会上升。

另一个经验是：状态机的“状态”和业务“数据”要分开。AirConditioner 里的温度、循环模式属于数据，它们可以在任意线程里原子更新；而当前模式属于状态机的核心状态，只能由handleEvent修改。如果把温度和状态搞混，比如在报文线程里直接改写mode变量，就可能出现一个线程读、另一个线程写的竞态。

4.3 C# 与 C++ 边界常见崩溃和 VSCode 调试

热搜词里有“c#调用c++出现 access violation c0000005”，这个问题在我做上位机的时候也撞到过，而且经常和状态对象生命周期的设计有关。

最常见的诱因是 C# 端拿到了一个 C++ 对象的指针，但 C++ 侧已经把这个对象析构了。状态模式里，如果状态对象是上下文内部临时new出来的，你把它作为一个返回值或参数通过 P/Invoke 传给了 C#，C# 侧拿着这个指针访问方法，C++ 侧又无法感知引用计数，于是访问已释放内存，触发 access violation。

正确的互操作模型是“句柄模型”：C++ 侧只对 C# 暴露不透明的句柄和几个简单的 C 风格接口，状态对象永远不跨边界传递。

extern "C" { void* ac_create(); void ac_destroy(void* handle); int ac_handle_event(void* handle, int event, int payload); int ac_get_mode(void* handle); }

C# 侧声明对应函数签名，用IntPtr保存句柄，所有状态逻辑保持在 C++ 内部。这样即便状态对象在 C++ 内部反复切换、销毁、重建，C# 侧看到的始终只是那个稳定的句柄。我建议所有 C++/C# 互操作项目都默认采用这套模式。

调试这类状态机问题，VSCode 是够用的。配置 C/C++ 插件后，先确认 tasks.json 里的编译任务能生成带调试信息的可执行文件，再在 launch.json 里把program指向正确的二进制路径，cwd设置成工作目录。我在 VSCode 里调试状态机有个小心得：不要只给handleEvent加断点，那样会断得眼花；直接对setState加条件断点，条件是目标状态等于某个关键值，这样只会停在真正的状态切换点。

4.4 异常恢复状态：连接断开、重连、重置设备

很多状态机只设计了“正常流程”，忘了设备通信还有大量异常分支。热搜词里那句“重置设备状态...连接设备失败”很典型，它就是异常恢复的场景。

设备断线、重连、重置失败，这些都不能直接用普通业务状态硬撑。我一般会在状态机里加一个DisconnectedState或ErrorState，它处理的不再是模式切换事件，而是超时、重连成功、重置完成这类系统事件。

比如收到一帧报文，但校验失败，连续失败三次后进入DisconnectedState。在这个状态下，用户的模式键、温度键都变得无效，或者只进入一个“重连中”的子状态。重连成功后再根据报文数据恢复到断线前的模式。如果直接就丢失了旧状态，就回到默认的 OffState。这样的设计比在业务状态里写if (disconnected) return;要干净得多。

那“重置设备状态”失败怎么办？我会在ErrorState里设计重试次数上限，超过上限就不再反复重置，而是报错并等待人工介入。这个上限和重试间隔最好是可配置项，方便现场调试。状态机必须能回答“现在这个状态，收到异常事件后能往哪走”，而不是把所有异常都塞进一个全局 try-catch。

5. 状态模式调试实录与问题速查

5.1 高频问题速查表

我在不同项目里收集到的高频问题，整理成速查表：

这张表我只列了高频问题，实际项目里还会出现各种组合场景。排查状态机问题时，我的第一反应永远是“打印当前状态、触发事件、目标状态”三个值，没有这三条信息，任何猜测都是浪费时间。

5.2 看状态机的三条调试技巧

第一，有条件断点，不要全断。在setState上打断点没问题，但要在里面再加一层条件，比如“新状态不是当前状态”才停。这样能过滤掉大量无变化的状态刷新。

第二，做状态日志时一定要带上时间戳和来源。自动空调这种设备，报文到达频率可能很高，如果只打印“Auto->Cooling”，你根本不知道是哪个事件来源导致的切换。我习惯把事件类型、报文序号、当前状态、目标状态、温度、循环标志一次性打到日志里，出问题后回看日志能直接复现完整时间线。

第三，善用std::visit的对当前值可视化。在 variant 实现里，调试器也许能看到 variant 的 index 和 active value，但不够直观。我经常在调试窗口手动调用一个to_string(const AcMode&)函数，把当前状态名直接打出来。虽然土，但非常有效。

5.3 从布尔标志位重构到状态模式的五步走

如果代码里现在已经堆了一堆 bool 和 if-else，想改成状态模式，我建议按这五步走。

第一步，把所有布尔标志位、模式字符串、临时状态码列出来，找出哪些组合是互斥的。比如is_cooling_和is_heating_理论上不能同时为真，这就说明它们其实共享同一个“工作模式”维度。

第二步，抽象出状态集合。把互斥的取值整理成Off / Auto / Cooling / Heating / FanOnly这样一组明确的枚举或类集合。

第三步，找出事件入口。哪些函数调用会引起标志位变化？把每一个变化点列成事件，比如“用户按模式键”、“收到报文”、“定时器超时”。

第四步，画状态转移表。这一步最花时间。不要画得完美才动代码，把已知的跳转关系先画出来，不确定的格子暂时标成“忽略”，把“忽略”也写成显式行为。

第五步，按选定的实现方式写代码。状态少用 variant，状态多且层级复杂的才认真引入多态。写完后把原来的 if-else 全部删掉，不要留一条旧的修改路径，否则状态机和旧逻辑会互相打架。

这套重构流程我走过不止一次，最大的心得是：先有转移表，再写代码。很多团队一上来就奔着设计模式去，结果代码写得很模式化，但转移规则根本没想清楚。转移表能逼着你把逻辑画出来，漏掉哪个分支一眼就能发现。

6. 我最后想说的话

写了这么多，回头看看自己最早那份全是布尔标志位的空调报文解析代码，最大的教训其实不是“该用状态模式”，而是“该早点分清状态和数据”。状态模式给了我一个很好的外壳，让我能按模式拆类，但真正让代码稳定下来的，是我想清楚了每个状态该响应什么事件、数据应该放在哪一层。

现在再遇到类似需求，我会先用 std::variant 把最小可运行版本拼出来，运行稳定后再决定往多态方向演化。状态模式不是银弹，它自己也存在生命周期、线程模型、扩展方向这些坑。但在 C++ 里谈状态管理，别再用一堆 bool 自欺欺人了。把状态变成显式的类型，哪怕是用最朴素的 switch 状态机，也比把模式藏在一堆分支里要强得多。如果你也正在做设备控制、报文解析、工作流引擎这类项目，强烈建议先把状态图画出来，再挑一种实现方式动手写。你会发现，模式切换的逻辑一旦显式化，调试和扩展的难度都会下降一个量级。