C++状态模式实战：用自动空调控制器重构if-else并排查崩溃

前阵子我在折腾一个自动空调控制端的逻辑，模块要接收温度报文，根据当前设置的模式去驱动压缩机和风门。第一版图省事，全用 if-else 堆，写完之后看着还能跑，等需求一加我就傻眼了。正好借这个项目把 C++ 里的状态模式完整重新梳理了一遍，代码重构完舒服得多。这篇就聊聊我踩过的坑、用到的套路，以及几个真实调试现场，希望能帮到正在被状态判断搅得焦头烂额的读者。

状态模式不是说背下来四个角色就完事，真正的难点在于怎么设计状态接口、怎么管理状态对象生命周期、什么时候不值得用。我会用一个自动空调控制器的例子贯穿全文，从 if-else 版本一路发展到状态机版本，最后再说说排查运行时崩溃的思路。

1. 为什么我把一段 if-else 堆出来的空调控制重构成了状态模式

1.1 一个控制器被需求写死的全过程

这个空调控制器的逻辑最初很简单：收到温度报文之后，对照目标温度决定要不要开压缩机。我随手写了几个 if 分支：

void AirConditioner::onTemperatureReport(float currentTemp) { if (mode == Mode::Cool) { if (currentTemp > targetTemp + hysteresis) { compressorOn(); } else { compressorOff(); } } else if (mode == Mode::Heat) { if (currentTemp < targetTemp - hysteresis) { heaterOn(); } else { heaterOff(); } } else if (mode == Mode::FanOnly) { fanOn(); } }

当时看着挺清晰，因为只有三种模式，每个模式两三个分支。后来需求开始长了：要加自动模式，自动模式下要根据温差决定走制冷还是制热；制热模式下要联动电辅热；送风模式要根据室内外温差决定引入新风还是循环通风；睡眠模式要逐步上调目标温度；还要处理断电恢复后回到之前的模式。

这类需求一来，函数内部就开始疯狂膨胀。每个新需求都要在所有分支里找一圈，看看哪里加了、哪里漏了。最痛苦的还不是自己写，是过了一个月回来看代码，要猜当时某个布尔变量为什么在某个分支里被置位。我记得某次同事加了个bBoostMode，参考了三个分支，却漏改了另一个分支，压缩机就一直不启动，找了一整天才定位到问题本质上是系统的行为随着“状态”不同而完全分岔，但我没有用状态来组织代码。

1.2 状态模式能省掉的到底是什么

那段时间我反复想一个问题：代码里最核心的复杂度来源是什么？答案是：同一类事件，在不同状态下，处理逻辑完全不一样。比如说“温度到了”这个事件，在制冷状态下要关压缩机，在制热状态下要开电辅热，在待机状态下什么都不做。if-else 把这个“状态维度的分岔”展开成了线性的条件判断，状态一多，判断就指数级膨胀。

状态模式的思路很朴素：把“当前处于什么状态”变成一个个对象，每个对象知道自己在当前状态下如何响应所有事件。事件来了直接丢给当前状态对象处理，不用自己去做一大堆分支判断。用生活里的话说，一个人开会时和休息时收到同样一条消息，反应完全不同，你不会每次都在大脑里写“如果我正在开会就怎样，如果我正在休息就怎样”，你会直接基于当前角色做出反应——角色就是状态对象。

所以我当时的重构目标就定为：空调的每个运行模式对应一个状态类，所有模式对事件的处理集中到各自的类里。新加一种模式，只新建一个类，不用再去读那些又长又绕的 if 分支。

2. 状态模式的 C++ 骨架怎么搭，才能少踩析构的坑

2.1 状态接口的设计，决定了你能省多少心

先定义状态基类。我在实际项目中习惯把AirConditioner作为上下文（Context）传入每个事件函数，因为状态对象需要回调上下文的开关方法，也需要触发状态切换。

// 状态基类 class AirConditioner; // 前置声明 enum class ACMode { Off, Idle, Cooling, Heating, FanOnly, Auto }; class ACState { public: virtual ~ACState() = default; // 收到模式切换指令 virtual void setMode(AirConditioner* ac, ACMode mode) = 0; // 收到温度报文 virtual void onTemperatureReport(AirConditioner* ac, float currentTemp) = 0; // 收到下电指令 virtual void powerOff(AirConditioner* ac) = 0; // 返回当前模式，便于日志和界面显示 virtual ACMode getMode() const = 0; };

有几个细节值得认真说。

第一，析构函数必须是virtual。因为后面所有状态类都是通过基类指针被delete的，如果析构不虚，就是一个明确的未定义行为，表现为状态对象里的资源没释放，甚至内存崩溃。这里不用override，因为析构函数的写法略有不同，写成virtual ~ACState() = default;就够了。

第二，状态接口的方法设计应该“以事件为粒度”，而不是“以功能为粒度”。我之前见过有人把状态接口设计成turnOnCompressor()、turnOffCompressor()、setFanSpeed()这种细粒度集合，结果每个状态类里都要空实现一大堆用不到的方法，又臭又长。正确做法是只暴露少量的高层事件，比如onTemperatureReport、setMode、powerOff，具体那些压缩机、风门操作由状态对象在内部调用上下文完成。

2.2 上下文对象怎么持有状态，怎么切换

上下文对象是状态模式的“壳”。它对外接收消息，对内委托给当前状态对象。

#include <memory> class AirConditioner { public: AirConditioner(); void setMode(ACMode mode); void onTemperatureReport(float currentTemp); void powerOff(); ACMode getCurrentMode() const; private: friend class ACState; void transitionTo(std::unique_ptr<ACState> nextState); std::unique_ptr<ACState> currentState_; float targetTemp_ = 26.0f; float hysteresis_ = 0.5f; };

注意transitionTo接收的参数是std::unique_ptr<ACState>，这意味着状态对象在创建并转移所有权时会明确表达“只有上下文拥有这个状态对象”。状态切换的本质就是替换currentState_：

void AirConditioner::transitionTo(std::unique_ptr<ACState> nextState) { if (!nextState) { return; } if (currentState_->getMode() == nextState->getMode()) { // 相同状态不重复切换 return; } currentState_ = std::move(nextState); }

这里有个很关键的工程问题：当前状态对象的成员函数里触发另一个状态切换，会发生什么？

假设CoolingState::onTemperatureReport内部调用了ac->transitionTo(std::make_unique<IdleState>())。transitionTo里把currentState_赋值为新对象，旧对象（这时候this指向的那个CoolingState实例）在unique_ptr的赋值过程中被析构。函数返回后，如果CoolingState::onTemperatureReport里还有任何读取this->xxx的语句，那就是典型的悬空 this 访问，表现就是 Windows 下常见的access violation c0000005崩溃，或者 Linux 下莫名的段错误。这个坑非常隐蔽，因为它不在你写代码的那一瞬间触发，而是取决于状态对象成员函数的尾部有没有访问成员。

我的做法是：状态对象里所有成员访问尽量集中在函数开头，需要切换状态时最后再调transitionTo，切换之后的代码一概不访问this。如果实在没法保证，那就做一个“延迟切换”——把下一个状态存到上下文里，等当前事件函数返回后由上下文的执行框架统一切换。后面第 5 节再展开讲这个崩溃的定位过程。

2.3 智能指针、裸指针还是表驱动，各有什么取舍

状态对象数量少、生命周期固定，用裸指针也能写。但状态切换频繁，裸指针一个不小心就 double free。我一开始也想用共享所有权，后来发现根本没有两个对象需要同时拥有状态，所以unique_ptr是最合适的，语义最清晰。

有一个替代方案也可以提一下：状态转移表。它的核心是std::map<std::pair<State, Event>, State>，用表驱动状态转移，代码量少，适合“转移逻辑简单、行为差异不大”的场景。但状态模式强调的是“每个状态对事件响应的逻辑也不一样”，比如制冷状态收到温度报文后要计算迟滞、控制压缩机，送风状态收到同样报文却要控制风门角度。这些行为差异在状态转移表里很难表达，得额外挂回调函数，反倒不如状态类里写虚函数直观。

3. 自动空调状态机的完整实现：状态、事件和转移表落地

3.1 需求拆解：把“状态、事件、行为”三个维度列出来

开始写代码前，先别急着建类。我跟团队的习惯是：把系统里所有运行模式列成状态，把自己的所有输入列成事件，把“当前状态下收到事件后的处理”填进一张表。这张表是后续写状态类的地图。

自动空调控制器最终定了 6 个状态：Off、Idle、Cooling、Heating、FanOnly、Auto。4 类事件：setMode、onTemperatureReport、powerOff、powerOn。其中powerOn在上下文的构造函数里直接触发，不算状态接口里的方法。

我整理过一张简化的转移表：

表格的好处是评审时一眼能看出漏掉了哪些转移。比如最开始我就漏了从Cooling直接切到FanOnly的行为，测试阶段才发现——用户从 app 上切模式，app 侧是直接下发模式报文的，不是先回 Idle 再切换。所以在状态接口里保留setMode后，每个状态都必须显式处理“外部模式切换”这个事件。

3.2 状态类的实现细节：以 Off 和 Cooling 为例

OffState的实现相对简单，但有个小细节：收到温度报文时什么都不做，不是忽略，而是要有日志。

#include <iostream> class OffState : public ACState { public: void setMode(AirConditioner* ac, ACMode mode) override { if (mode == ACMode::Off) { return; } // 从关机进入待机，再让待机状态去处理模式 ac->transitionTo(std::make_unique<IdleState>()); ac->setMode(mode); } void onTemperatureReport(AirConditioner* ac, float currentTemp) override { // 关机状态下温度报文没有意义，但保留一个入口打日志 std::cout << "[OffState] ignore temperature report: " << currentTemp << std::endl; } void powerOff(AirConditioner* ac) override { // 已经是关机，无需处理 } ACMode getMode() const override { return ACMode::Off; } };

注意setMode里我调用了transitionTo(IdleState)后又调用了ac->setMode(mode)。这里有个过程：先把状态切到 IdleState，再让 IdleState 去接管后续的模式处理，这比在 OffState 里重复实现一套“模式切换”逻辑要干净得多。这就是状态模式的一个轻松之处——分析移交上下文。

CoolingState是文章的核心逻辑所在：

class CoolingState : public ACState { public: CoolingState(float targetTemp, float hysteresis) : targetTemp_(targetTemp), hysteresis_(hysteresis) {} void setMode(AirConditioner* ac, ACMode mode) override { switch (mode) { case ACMode::Cooling: break; case ACMode::Heating: ac->transitionTo(std::make_unique<HeatingState>()); break; case ACMode::FanOnly: ac->transitionTo(std::make_unique<FanOnlyState>()); break; case ACMode::Auto: ac->transitionTo(std::make_unique<AutoState>()); break; default: // 切到待机 ac->transitionTo(std::make_unique<IdleState>()); break; } } void onTemperatureReport(AirConditioner* ac, float currentTemp) override { // 1. 如果已经达到目标，进入待机，关闭压缩机 if (currentTemp <= targetTemp_ - hysteresis_) { ac->transitionTo(std::make_unique<IdleState>()); return; } // 2. 没达到就继续制冷，温度越高压缩机的开度越大，简化为比例控制 float delta = currentTemp - targetTemp_; int duty = static_cast<int>(std::clamp((delta / 3.0f) * 100.0f, 20.0f, 100.0f)); ac->setCompressorDuty(duty); } void powerOff(AirConditioner* ac) override { ac->transitionTo(std::make_unique<OffState>()); } ACMode getMode() const override { return ACMode::Cooling; } private: float targetTemp_; float hysteresis_; };

这里把比例控制放进了状态类内部。你可能注意到：状态不是纯粹只负责切换，它也可以携带自己的参数。比如制冷的目标温度、迟滞，都是CoolingState构造时传进来的。状态类不只是“我是制冷”，它还知道自己这轮制冷要干什么。这比在 Context 里维护一堆currentState加stateParams的散装结构更内聚。

HeatingState和FanOnlyState的结构几乎一样，核心就是onTemperatureReport分支不同：制热是低于目标温度才开加热，送风则基本不管温度，只根据室内外温差调风门。真正复杂的是AutoState。

3.3 AutoState 的组合式处理：避免状态爆炸

AutoState不能写成“又制冷又制热”的四不像，否则就是把所有 if-else 又塞回了一个状态类里。我的做法是：AutoState内部根据温差决定“委托”给CoolingState或HeatingState处理具体执行，自己只做一个裁决者。

class AutoState : public ACState { public: void setMode(AirConditioner* ac, ACMode mode) override { if (mode == ACMode::Auto) { return; } ac->transitionTo(std::make_unique<IdleState>()); ac->setMode(mode); } void onTemperatureReport(AirConditioner* ac, float currentTemp) override { float target = ac->getTargetTemp(); if (currentTemp > target + 1.0f) { // 应该制冷 ac->transitionTo(std::make_unique<CoolingState>()); ac->onTemperatureReport(currentTemp); // 复用制冷状态的处理 } else if (currentTemp < target - 1.0f) { ac->transitionTo(std::make_unique<HeatingState>()); ac->onTemperatureReport(currentTemp); } else { // 温度接近目标，待机 ac->transitionTo(std::make_unique<IdleState>()); } } ACMode getMode() const override { return ACMode::Auto; } };

这里其实出现了一个小小的“递归决策”：AutoState判断完温度后切到具体模式，再重新调用一次温度事件处理。好处是制冷、制热的行为细节不用在自动状态里复制一份；坏处是如果切换后的状态又立刻判断条件不满足，可能会产生抖动，所以我在代码里用+1.0f和-1.0f做了滞回，避免温度在一度附近反复横跳。

这个案例想说明的是：状态模式可以组合使用。状态之间不是只能兄弟关系，一个聚合状态可以持有“实际执行策略”的引用或临时切换到那些策略状态。真实项目里状态模式往往用于表达宏观状态，组合模式或者策略模式用于表达微观手法，两层叠起来用。

3.4 代码落地时的工程细节

• 状态类的构造和析构要轻量。状态切换非常频繁，如果每次切换都在堆上 new 一个对象，内存分配器压力会很大。我有一次在嵌入式环境里跑，发现 mcu 上的堆碎片化严重，排查下来就是状态对象频繁 new/delete。后来改成构造时传参已有状态对象并尽量缓存复用，或者使用对象池，问题就缓解了。
• 尽量把每个状态类放进单独一个.h/.cpp，避免在一个巨型的state_impl.cpp里堆十个类。我是按状态拆文件编译的，增删状态时改动范围更小。
• 上下文和状态之间双向引用，要防止循环依赖。我用前置声明class AirConditioner;放在状态头文件里，真正的功能依赖放在.cpp中。

4. 状态模式真正能落地的场景，以及三个容易翻车的点

4.1 游戏、协议连接、UI 流程——三个高契合场景

除了空调控制器，我在其他几个项目里也用状态模式重构过，效果都不错。

游戏角色是一个经典例子。待机、移动、攻击、受击、死亡，每个状态下同一帧输入的处理完全不同。我在一个 2D 小游戏里用状态类去管理角色动画状态，每次按键事件只委托给当前状态，释放技能、位移、碰撞检测都在对应状态类里实现，比在游戏主循环里堆if (state == ATTACK && ...)清晰太多了。

协议连接则是另一个收益高的场景。设备端连接服务器，存在“未连接、连接中、已握手、运行中、重试中、失败”等多个状态。握手失败后不是直接回到未连接，而是需要进入一个“重试”状态，重试次数耗尽才进入“失败”状态，且允许用户手动重置回初始态。这里如果把“握手失败”处理成“回到未连接”，逻辑上是错的，因为你可能永远不知道这次重试失败和上次失败的区别。状态对象可以让‘失败’状态知道自己已经失败了几次，保存重试计数，从而决定是继续重试还是进入不可恢复的错误态。

UI 导航流程里，状态模式也常见：主菜单、设置页、播放页、暂停页。每个页面下按下返回键的行为都不一样，切页就是一个状态切换。这类场景用状态模式的负载很轻，写起来也最轻松。

4.2 别为了模式而模式：什么时候真的不如 if-else

我得诚实说：状态模式不是万能药，有几种场景用它纯属白费功夫。

一种是状态数量少于 3，且事件类型只有两三种。比如只是判断“开关”两态，if（isOn）就够了，强行建两个类再加上下文，增加理解成本。第二种是状态之间几乎不会迁移，各状态的事件响应也都各管各的，那其实就是普通的多态分发，不需要状态机语义。第三种是事件处理的行为差异极小，比如不同状态下都只是打印不同的日志，用查表法更轻。

我判断是否值得用状态模式的标准很简单：拿一张纸，把“状态数 × 事件数”算一算。如果乘积差不多等于代码分支的数量，且以后状态还会稳定扩展，那状态模式是划算的；如果状态就是三五个、事件永远就两个，那写枚举加 switch 反而更直观。

4.3 状态模式和策略模式的区别，我的区分方法

面试和代码评审中经常有人把状态模式跟策略模式搞混。我自己的判断方式：

策略模式解决的是“同一件事的不同做法换着用”。比如排序算法，一个Sorter持有SortStrategy，下游可以动态切换快排或归并。这时候根本没有“状态迁移”的概念，策略对象之间也不存在谁能触发谁变成谁。

状态模式则天然带着“当前状态会演化”的概念。一个状态对象的成员函数里往往会触发上下文把当前状态变成另一个状态。策略模式里，Context 选择策略，策略不会让 Context 变成另一种 Context；状态模式里，当前状态对象可以直接改变它自己所属的那个壳的身份。

有个直接的代码层面判断技巧：如果把这套类的转移逻辑删掉，代码还能正常自洽，那大概率是策略模式；如果删掉状态转移，代码就没法工作，那才是状态模式。

5. 一次访问违例的定位实录：状态日志是第一破案工具

5.1 现象：收到温度报文后程序崩溃

项目是用 VSCode + CMake 搭的 C++20 工程，跑在 x86 Linux 上做半实物仿真。一切正常跑了几分钟，某次收到一个外部温度报文后，程序直接崩溃。控制台打出一堆信息，隐约看到Segmentation fault。当时我的第一反应是检查数组越界，但仔细看崩溃消息，栈顶指向的是CoolingState::onTemperatureReport，这是个纯逻辑函数，里面没有任何裸数组访问。

为了能把崩溃现场看得更清楚，我打开了 core dump，然后gdb里 bt 一看，完全傻眼：栈帧里的this指针已经指向一个被释放的堆地址。这意味着我在状态对象已析构的代码路径里还在执行它的成员函数。

5.2 第一步：打开状态日志，画一条非法转移路径

排查这种问题，我的第一个操作永远不是断点，而是给状态切换和关键事件入口加上日志。我用的日志库是 spdlog，配一个最简单的同步日志器就够了：

#include <spdlog/spdlog.h> void AirConditioner::transitionTo(std::unique_ptr<ACState> nextState) { if (!nextState) { spdlog::warn("transitionTo with null state"); return; } auto oldMode = currentState_ ? currentState_->getMode() : ACMode::Off; auto newMode = nextState->getMode(); spdlog::info("state transition: {} -> {}", modeToString(oldMode), modeToString(newMode)); if (oldMode == newMode) { return; } currentState_ = std::move(nextState); }

加完日志重启复现，输出序列是这样的：

[14:02:33.112] state transition: Cooling -> Idle [14:02:33.113] CoolingState::onTemperatureReport

看到没有，问题来了：日志显示程序已经从Cooling切换到了Idle，可紧接着又执行了CoolingState::onTemperatureReport。这说明那次温度报文的事件分发是异步或者延迟的，事件到达时状态已经变成 Idle，但它仍然拿着旧状态的指针去调用了CoolingState的方法。

这个场景在我的实现里更具体：我在CoolingState::onTemperatureReport开头判断温度已经达标，就调用了transitionTo(IdleState)，然后这个函数返回。按理说函数返回后不应该再访问 this。但实际代码里我在状态切换后还有一行spdlog::info("cooling now stop, currentTemp={}", currentTemp_)，正是因为这一行读取了成员变量，才把悬垂 this 的崩溃暴露了出来。

5.3 根因：状态对象生命周期管理失误

这个 bug 的根源有几层。

第一层是代码写法上：我在状态对象成员函数内部触发状态切换，切换一瞬间自己的内存就被释放了，函数后续代码继续用 this 就是典型悬垂指针。这其实是一个设计约定问题，不算编译器层面的错误，所以运行时才会时好时坏。

第二层是日志打印的位置太靠后。如果我在onTemperatureReport一进入就打印入口日志，调试时能更早看到“进入 CoolingState”和“切出 CoolingState”的顺序。现在日志只在 transitionTo 里打，看不到“成员函数入口”这个标记，所以一开始我误以为是异步事件重复分发。

最终的修复我选择的是“延迟切换”方案。在上下文里增加一个待切换状态变量，状态对象成员函数里只发出切换请求，真正执行transitionTo的时机放到事件循环总控里：

class AirConditioner { // ... void requestTransition(std::unique_ptr<ACState> nextState); void executePendingTransition(); private: std::unique_ptr<ACState> currentState_; std::unique_ptr<ACState> pendingState_; }; void AirConditioner::requestTransition(std::unique_ptr<ACState> nextState) { pendingState_ = std::move(nextState); } void AirConditioner::executePendingTransition() { if (!pendingState_) { return; } transitionTo(std::move(pendingState_)); }

然后在onTemperatureReport入口先执行executePendingTransition()，再进入当前状态的事件分发。这样任何状态对象内部发起的切换请求，都会攒到下一轮事件进入之前统一执行，彻底消除了状态对象在成员函数执行期间被析构的可能。代价是多了一次间接调用，但对空调控制器这种低频事件场景完全够用。

6. 状态模式在面试里怎么答，才能透出实战经验

6.1 和策略模式、状态机的本质区别怎么说

面试官问“谈谈状态模式”时，很多人会把概念背得滚瓜烂熟，但一追问就跟策略模式混了。我给一个清晰的对比话术：

策略模式是替换算法，状态模式是表达对象的行为随状态迁移而改变的机制。一个排序类换排序算法，是策略模式，因为Sorter对象本身身份不会变；一个空调从制冷切到制热，是状态模式，因为‘当前状态’从制冷对象切到制热对象，后续所有温度响应行为都跟着变。

再补充一层：“状态机”和“状态模式”不是一回事。状态机关注“在某个状态收到某事件应该转移到哪个状态”，描述的是转移表；状态模式关注“在某个状态下收到某事件应该执行什么行为”，描述的是多态分发。工程上两者经常一起用：状态转移表负责决策，状态模式负责执行。

这个回答展开到位，面试官基本能确认你不是只背了八股。

6.2 一个面试应答示例：从‘我会用’到‘我踩过坑’

如果面试官让我举个例子，我会把空调控制器这个项目摆出来，完整讲述一遍：

“我做过一个自动空调控制器，六个状态四类事件。最初用 if-else，后来状态多了重构成状态模式。状态基类定义setMode、onTemperatureReport、powerOff三个事件接口，每个具体状态实现自己的响应逻辑。我遇到过状态对象成员函数内部触发状态切换，切换后旧对象被析构，函数后续访问 this 导致访问违例的坑，这个我用延迟切换解决——状态对象只请求切换，上下文在下一轮事件入口统一执行。实际收益是加新状态时只需要新增状态类并补充转移表，不用动既有代码。”

这段话里包含了我实际做过的事、我遇到的具体问题、我的解决方案、我的收益评估。比“状态模式有四个角色，上下文保存状态，状态对象定义行为”这种干巴巴定义有说服力得多。

技术面试还喜欢问 C++ 层面的细节：为什么状态接口析构要虚、为什么用unique_ptr而不是shared_ptr、状态模式下虚函数开销可不可以接受。我的答案是：析构虚函数保证多态删除安全；unique_ptr表达独占所有权，状态对象不会被共享；虚函数开销在这个场景下可以忽略，毕竟事件频率远低于函数指针间接调用带来的收益。

最后再分享一点个人落地习惯

状态模式我用了几年，最大的体会是：它省的是“以后加状态时的脑袋负担”，而不是“现在写代码的手指负担”。前期建类、写接口确实比写 if-else 麻烦，但项目一旦进入维护期，收益很快就体现出来了。

我个人还有一个习惯：状态转换一律打印到日志，并把日志格式统一成“状态 -> 状态，原因”这样一行，后续排查任何偶发问题都有据可查。这套日志在我定位那轮访问违例时帮了大忙，否则光靠断点很难复现偶发崩溃。

另外一个建议是扩展时别贪多。状态模式很容易被过度设计——我看到过有人为了一个开关状态建了四个文件四个类，维护成本直线上升。先用简单的枚举加 switch 撑住，当分支开始成倍增长、你在 switch 里反复寻找“到底漏了哪个状态没处理”的时候，再迁移到状态模式也不迟。知道什么时候不用，比知道怎么用更宝贵。