我最近重读设计模式里的状态模式，脑子里浮现的是之前维护过的一个设备控制程序。那个程序的连接、配置、运行、错误几个状态全写在一个大类里，肉眼可见的只有一堆枚举和 if-else，每次加一个协议分支都要把整个文件重新审一遍。后来我把它完整改成状态模式，才对这套模式在 C++ 里的落地方式有了真实体感。这篇文章就把我从“枚举加 switch”重构到状态对象，再到解决切换线程安全和状态类爆炸问题的全过程写出来，适合那些已经能画状态图、但一落到 C++ 代码就纠结“状态放哪、切换由谁触发、状态对象怎么管理”的读者。读完你不仅能直接抄到一个可编译的状态机骨架，还能在真正动手前判断这套模式到底适不适合你的场景。
1. 从一段失控的代码说起：状态模式到底消灭了什么
1.1 一个真实项目的膨胀过程
最初那版代码看起来非常“简单”。一个枚举成员变量，一个入口处理函数，里面是巨大的 switch：
enum class DeviceStatus { Idle, Connecting, Configuring, Running, Error }; class DeviceController { public: void handleEvent(Event e) { switch (status_) { case DeviceStatus::Idle: if (e == Event::StartConnect) { status_ = DeviceStatus::Connecting; startConnect(); } break; case DeviceStatus::Connecting: if (e == Event::Connected) { status_ = DeviceStatus::Configuring; loadProfile(); } else if (e == Event::Timeout) { status_ = DeviceStatus::Error; notifyError(ErrorCode::ConnectTimeout); } break; // 后面还有 Configuring、Running、Error 一大段 } } private: DeviceStatus status_; int retryCount_; Timer connectTimer_; // 每个状态都有自己的临时变量，全部堆在这里 };前两个版本确实快，新增一个事件只需要多加一个 case 分支。但状态数涨到五个之后，问题就出现了：每个 case 里做什么操作、切换后要清理哪些临时变量，只有在完整读过整个函数后才能判断。最难受的是那些“当前状态下不会出现、但别人不敢删”的分支，因为它们在其他状态里可能是合法的。每个状态需要的临时数据也被迫平铺在控制器里：连接超时计时器只在 Connecting 有用，重试计数只在 Error 恢复时有用，但它们全都在同一个作用域里，导致构造函数里要逐个初始化，析构时还要小心清理顺序。
这就是状态模式要解决的核心问题：让状态自己拥有自己的行为和数据，而不是把所有的状态逻辑揉在同一个类里。一旦“当前处于什么状态”变成一个可以被替换的对象，事件处理就从“遍历所有状态的 switch”变成了“让当前状态对象自己回答该怎么办”。
1.2 “把状态变成对象”的第一次重构
重构后的结构很直白：一个状态接口，几个具体状态类，一个持有当前状态指针的上下文类。
- 状态接口声明这个上下文在某个状态下收到事件时应该做什么。
- 具体状态实现该状态下的事件响应，并且决定下一个状态是谁。
- 上下文只做两件事：转发外部请求给当前状态，以及提供一个“更换当前状态”的入口。
设备控制器里的DeviceController::handleEvent从几十行 switch 缩成了三行转发：
void DeviceController::handleEvent(Event e) { state_->handle(*this, e); }而原来各 case 里的业务逻辑，被分散到ConnectingState::handle、ConfiguringState::handle等各自的状态类中。第一次这样改完，我的感觉是“原来那些纠缠在一起的分支，现在终于有了明确的家”。状态模式并没有消灭逻辑，它消灭的是“所有逻辑共享一个作用域”的混乱感。
2. 一个可以跑的播放器示例：教科书实现里没说的内存陷阱
2.1 三个角色和它们的分工
先说清楚每个角色的职责，后面代码才不会看晕。
PlayerState：状态接口，定义play、pause、stop三个操作。StoppedState/PlayingState/PausedState：具体状态，自己决定收到操作后做什么、要不要切换。Player：上下文，保存当前状态指针，把外部请求转发给当前状态。
教科书画这种类图时通常很轻松，但落到 C++ 就会遇到一个绕不开的问题：状态对象用什么所有权模型管理？这一节我先把最容易想到的写法写出来，然后告诉你它为什么会在实战中咬人。
2.2 看起来最简单的写法：在切换瞬间的析构风险
先看一个常见的“朴素实现”：
#include <iostream> #include <memory> class Player; class PlayerState { public: virtual ~PlayerState() = default; virtual void play(Player& p) = 0; virtual void pause(Player& p) = 0; virtual void stop(Player& p) = 0; virtual const char* name() const = 0; }; class Player { public: Player(); void setState(std::unique_ptr<PlayerState> next) { state_ = std::move(next); } void play() { state_->play(*this); } void pause() { state_->pause(*this); } void stop() { state_->stop(*this); } void showCurrentState() const { std::cout << "current: " << state_->name() << std::endl; } private: std::unique_ptr<PlayerState> state_; };然后是三个状态类：
class StoppedState : public PlayerState { public: void play(Player& p) override; void pause(Player& p) override; void stop(Player& p) override; const char* name() const override { return "Stopped"; } }; class PlayingState : public PlayerState { public: void play(Player& p) override; void pause(Player& p) override; void stop(Player& p) override; const char* name() const override { return "Playing"; } }; class PausedState : public PlayerState { public: void play(Player& p) override; void pause(Player& p) override; void stop(Player& p) override; const char* name() const override { return "Paused"; } };状态实现如下：
void StoppedState::play(Player& p) { std::cout << "[Stopped] 开始播放" << std::endl; p.setState(std::make_unique<PlayingState>()); } void StoppedState::pause(Player&) { std::cout << "[Stopped] 未在播放，忽略暂停" << std::endl; } void StoppedState::stop(Player&) { std::cout << "[Stopped] 已经停止" << std::endl; } void PlayingState::play(Player&) { std::cout << "[Playing] 正在播放中" << std::endl; } void PlayingState::pause(Player& p) { std::cout << "[Playing] 暂停" << std::endl; p.setState(std::make_unique<PausedState>()); } void PlayingState::stop(Player& p) { std::cout << "[Playing] 停止" << std::endl; p.setState(std::make_unique<StoppedState>()); } void PausedState::play(Player& p) { std::cout << "[Paused] 继续播放" << std::endl; p.setState(std::make_unique<PlayingState>()); } void PausedState::pause(Player&) { std::cout << "[Paused] 已经暂停" << std::endl; } void PausedState::stop(Player& p) { std::cout << "[Paused] 停止" << std::endl; p.setState(std::make_unique<StoppedState>()); }最后补上构造函数并跑一下：
Player::Player() : state_(std::make_unique<StoppedState>()) {} int main() { Player player; player.play(); player.pause(); player.play(); player.stop(); player.showCurrentState(); return 0; }这段代码在大多数编译器上能正常跑出预期输出。但请注意PlayingState::stop内部这一行：
p.setState(std::make_unique<StoppedState>());setState会执行state_ = std::move(next)，也就是说，当前正在执行stop的那个PlayingState对象，在stop返回前就被unique_ptr销毁了。这就是一个隐形的delete this场景。只要你在stop里切换状态之后还访问了this的任何一个成员，或者再来一次虚函数调用，就是未定义行为。
我在自己的项目里第一次踩到这个坑时，表现是：状态切换后，下一帧偶尔打印出“当前状态: 未知对象”。排查很久才发现，切换后析构顺序和执行栈完全取决于编译器优化。教科书很少提醒这一点的原因，是很多例子里状态对象是静态共享的，而一旦把状态做成带数据的、每次进入都 new 出来的对象，这个问题就避不开。
2.3 工程里我更推荐的两套变形
第一套：延迟提交切换。外部接口调用状态方法时只记录“想切到哪个新状态”，等状态方法完整返回后再真正替换指针。这样旧状态的析构发生在调用栈回到外部入口之后，绝对不会在状态成员函数体内被销毁。
class Player { public: Player(); void changeState(std::unique_ptr<PlayerState> next) { pendingState_ = std::move(next); } void play() { state_->play(*this); commitPendingState(); } void pause() { state_->pause(*this); commitPendingState(); } void stop() { state_->stop(*this); commitPendingState(); } private: void commitPendingState() { if (pendingState_) { state_ = std::move(pendingState_); } } std::unique_ptr<PlayerState> state_; std::unique_ptr<PlayerState> pendingState_; };状态内部就把setState改成changeState，逻辑上几乎无差别，但旧状态的析构被推迟到了安全点。对于“每个状态都有自己的私有数据”的场景，这套写法最省心。
第二套：状态完全无状态化，用静态实例避免内存问题。如果状态类本身不携带数据，只负责行为逻辑，那么让它成为单例是非常好的选择：
class StoppedState : public PlayerState { public: static const StoppedState& instance() { static StoppedState s; return s; } void play(Player& p) override; void pause(Player& p) override; void stop(Player& p) override; const char* name() const override { return "Stopped"; } };此时上下文可以改成保存裸指针：
class Player { public: Player() : state_(&StoppedState::instance()) {} void changeState(const PlayerState& next) { state_ = &next; } // play/pause/stop 转发逻辑不变 private: const PlayerState* state_; };这套写法的最大好处是：切换状态只是一次指针赋值，无分配、无析构、绝对没有delete this风险。缺点也很明显：状态类不能保存“这次进入状态时的瞬时数据”。所以继续往下之前，你需要想清楚：数据到底放在状态里，还是放在上下文里。
3. 状态迁移逻辑放哪边：内部迁移还是外部调度
状态模式看起来只是三个角色的结构，但真正设计时最容易吵起来的问题是：两个状态之间怎么切换，这段逻辑写在谁那里。
3.1 方案A：迁移动作全放在上下文
让状态对象只暴露基础操作，比如onPlay、onPause、onStop，状态类内部完全不调用changeState。上下文收到事件后，先问当前状态“你是什么状态”，再根据一张迁移表决定新状态。
void Player::play() { if (state_ == &StoppedState::instance()) { state_ = &PlayingState::instance(); } else if (state_ == &PausedState::instance()) { state_ = &PlayingState::instance(); } state_->onPlay(*this); }这种集中式写法的优点是迁移关系一目了然：整个状态机的所有跳转都摆在上下文同一个函数里，评审代码时对着状态图一行行核对即可。缺点是上下文要认识每个具体状态类，状态越多这个分派函数就越臃肿；而且状态对事件的响应不再是纯粹的“自己决定”，封装性会弱一些。
3.2 方案B：迁移动作放在状态内部
前面播放器例子属于这种：每个状态自己决定“收到 play 后我切到哪个状态、收到 stop 后我切到哪个状态”。
void PlayingState::pause(Player& p) { p.changeState(std::make_unique<PausedState>()); }优点是状态的内聚性最强，新增一个状态时，只需要写它自己的行为，不太需要改动上下文。缺点是状态多了以后，全局迁移关系被分散到十几个状态类里，只看某个状态类的代码可以理解“它离开后去哪”，但很难一眼看出整个状态机长什么样。
3.3 我的选择标准
我的经验法则很简单：状态数量少于 5 个时用集中式，状态数量超过 5 个且每个状态里都有独立的业务逻辑时用内部迁移。集中式适合“状态关系像一个固定表格”的产品，内部迁移适合“同一个状态对不同事件响应差异巨大”的系统。
还有一个现实考量：如果团队里维护状态图的文档，内部迁移反而更好用。因为状态图本身就是“从状态A到状态B”的箭头集合，而每个状态类恰好就是图里的一个节点；改一个节点只需要打开一个文件。反过来，如果团队没有状态图，迁移逻辑散在各处会变得很难梳理，这时候宁可牺牲部分封装，也要把迁移表集中到一棵树上。
4. 实战前必须处理的三个问题
4.1 对象爆炸与状态内存管理
状态模式最大的代价是类数量激增。一个业务里如果有十个状态，哪怕每个状态只有三四个方法，也要写十个类、三四十个函数。很多“状态”其实只有行为差异、没有任何私有数据，这种状态应该做成静态单例。
我见过一些项目为了省事，把所有状态都用new创建然后让上下文持有，结果整个运行期到处是动态分配，不仅慢，还要小心翼翼地处理释放。实际上无数据状态用静态实例就够了，上下文切换只需要比价一个指针。只有那些需要携带私有数据的“有状态状态”，才值得用unique_ptr加延迟提交管理。
4.2 状态之间怎么传数据
状态 A 想去状态 B，但 B 进入时需要 A 的一些计算结果，最直接的做法是构造 B 时把数据传进去：
p.changeState(std::make_unique<FailedState>(errorCode));这很好，但有代价：如果这些数据反过来后续还要被上下文或其他状态读取，最自然的方式其实是把共享数据放到上下文里。比如游戏 AI 里，敌人坐标属于所有状态都能读取的信息，那它就应该是上下文的一个成员。我的建议是：一次性的、状态启动时需要的参数用构造函数注入；跨状态共享的、随时会被外部更新的数据放上下文。这样既不会让构造函数参数列表失控，也不会让上下文膨胀成一个上帝对象。
4.3 用现代 C++ 给状态类减负
状态类里大量重写虚函数，很容易写出样板代码。几个实用技巧：
- 用
override明确标记重写函数，编译期就能抓住签名不一致的问题。 - 空操作的虚函数可以在基类给默认实现，而不是在每个状态里重复写空函数体。
- 如果状态切换后需要做进入动作，统一定义一个
onEnter，由上下文在提交切换后调用，避免每个状态在构造函数里做不完整的初始化。
这些细节不会改变状态模式的结构，但能让十个状态类看起来整洁很多，也让后来接手的人更容易找到差异在哪里。
5. 和表驱动状态机、std::variant 方案怎么选
5.1 表驱动状态机
状态模式并不是 C++ 里状态机的唯一答案。很多项目里你会看到一张“状态-事件-动作”的表：
struct Transition { State from; Event event; State to; void (*action)(Actor&); }; static const Transition transitions[] = { { State::Idle, Event::Move, State::Moving, Actor::startMove }, { State::Moving, Event::Stop, State::Idle, Actor::stopMove }, // ... }; void dispatch(Actor& actor, State current, Event e) { for (const auto& t : transitions) { if (t.from == current && t.event == e) { actor.currentState = t.to; t.action(actor); return; } } }表驱动的好处是极其直观，所有迁移都在一张表里，审计方便，甚至在产品需求变化时可以直接改数据文件而不动代码。坏处是如果某个状态的“动作”不是简单函数而是需要访问很多私有数据，那要么把逻辑塞进函数指针里，要么得单独维护一个动作注册表。它适合状态数量大、事件矩阵固定、动作粒度足够小的场景。
5.2 基于 std::variant 的静态状态机
C++17 以后，std::variant也成了状态机的常见武器。每个状态是一个结构体，所有状态组成一个variant：
struct IdleState {}; struct PlayingState { float startTime; }; struct PausedState { float pauseTime; }; using PlayerState = std::variant<IdleState, PlayingState, PausedState>;每次处理事件时，用std::visit对不同状态分支处理，需要切换状态就返回一个新的variant：
void Player::play() { state_ = std::visit([](auto&& s) -> PlayerState { using T = std::decay_t<decltype(s)>; if constexpr (std::is_same_v<T, IdleState>) { return PlayingState{ currentTime() }; } else if constexpr (std::is_same_v<T, PausedState>) { return PlayingState{ currentTime() - s.pauseTime }; } else { return s; } }, state_); }这种写法的最大优势是类型安全，编译器保证你不需要虚函数的动态分发，读取状态数据就像读普通结构体一样直接。缺点也很明显：当一个visit分支里需要处理超过四五个分支时，lambda 会变得很臃肿；而且每个状态对象都保存在variant的栈空间里，如果单个状态携带超大结构体，variant的尺寸会取所有成员的最大值，内存占用会比指针方案高。
5.3 一张选型对照表
| 方案 | 适合状态个数 | 迁移关系可读性 | 每个状态的封装性 | 额外内存/性能成本 |
|---|---|---|---|---|
| 枚举 + switch | 5 个以内 | 差 | 差 | 零成本 |
| 状态模式 | 5 到 20 个 | 中到高 | 高 | 虚函数调用 + 状态对象开销 |
| 表驱动 | 状态多、事件矩阵固定 | 极高 | 低 | 查找表开销小 |
| std::variant | 5 个左右、逻辑清晰 | 中 | 中 | 无虚函数，但可能增大对象尺寸 |
实际操作中我不会把状态模式当成默认选择。小于等于三个状态、逻辑又简单，直接 switch 就够了；五到十几个状态且行为差异明显，状态模式最合适；如果迁移关系像一张规整的矩阵，表驱动胜出；如果恰好每个状态就是几行结构体加一个 lambda，variant 会成为最轻快的选择。这几种方案之间是互补关系，不是替代关系。
6. 实战案例：一个守卫 AI 的巡逻、警戒、攻击、逃跑
6.1 需求拆解
我用一个简化的守卫 AI 把前面所有的设计点串起来。需求很简单：
- 默认巡逻，发现敌人进入警戒。
- 警戒时敌人进入射程，立刻攻击。
- 攻击时敌人脱离射程，回到警戒。
- 攻击时自身血量过低，逃跑。
- 逃跑时敌人消失，回到巡逻。
这里状态之间需要共享的数据只有两个：当前血量和敌人是否可见。所有状态都没有私有数据，所以采用静态实例的方案最干净。
6.2 核心实现
先把基类和事件定义出来：
#include <iostream> class Guard; enum class GuardEvent { SpottedEnemy, EnemyLost, EnterRange, LeaveRange, HealthLow }; class GuardState { public: virtual ~GuardState() = default; virtual void onEnter(Guard&) {} virtual void update(Guard&, float dt) {} virtual void onEvent(Guard&, GuardEvent) {} virtual const char* name() const = 0; };再定义四个状态和共享数据的守卫类：
class PatrolState; class AlertState; class AttackState; class FleeState; class Guard { public: Guard(); void changeState(const GuardState& next) { pendingState_ = &next; } void update(float dt) { state_->update(*this, dt); commitPendingState(); } void handleEvent(GuardEvent e) { state_->onEvent(*this, e); commitPendingState(); } float health() const { return health_; } void setHealth(float h) { health_ = h; } const char* currentName() const { return state_->name(); } private: void commitPendingState(); const GuardState* state_ = nullptr; const GuardState* pendingState_ = nullptr; float health_ = 100.0f; };具体状态类，每个状态只关心自己该处理的事件：
class PatrolState : public GuardState { public: static const PatrolState& instance() { static PatrolState s; return s; } void onEvent(Guard& g, GuardEvent e) override; const char* name() const override { return "Patrol"; } }; class AlertState : public GuardState { public: static const AlertState& instance() { static AlertState s; return s; } void onEnter(Guard& g) override; void onEvent(Guard& g, GuardEvent e) override; const char* name() const override { return "Alert"; } }; class AttackState : public GuardState { public: static const AttackState& instance() { static AttackState s; return s; } void onEnter(Guard& g) override; void update(Guard& g, float dt) override; void onEvent(Guard& g, GuardEvent e) override; const char* name() const override { return "Attack"; } }; class FleeState : public GuardState { public: static const FleeState& instance() { static FleeState s; return s; } void onEnter(Guard& g) override; void update(Guard& g, float dt) override; void onEvent(Guard& g, GuardEvent e) override; const char* name() const override { return "Flee"; } };实现部分：
Guard::Guard() : state_(&PatrolState::instance()) { state_->onEnter(*this); } void Guard::commitPendingState() { if (pendingState_ && pendingState_ != state_) { state_ = pendingState_; state_->onEnter(*this); } pendingState_ = nullptr; } void PatrolState::onEvent(Guard& g, GuardEvent e) { if (e == GuardEvent::SpottedEnemy) { std::cout << "[Patrol] 发现敌人，进入警戒" << std::endl; g.changeState(AlertState::instance()); } } void AlertState::onEnter(Guard& g) { std::cout << "[Alert] 警戒中" << std::endl; } void AlertState::onEvent(Guard& g, GuardEvent e) { if (e == GuardEvent::EnemyLost) { std::cout << "[Alert] 敌人消失，回到巡逻" << std::endl; g.changeState(PatrolState::instance()); } else if (e == GuardEvent::EnterRange) { std::cout << "[Alert] 敌人进入射程，切换到攻击" << std::endl; g.changeState(AttackState::instance()); } } void AttackState::onEnter(Guard& g) { std::cout << "[Attack] 开始攻击" << std::endl; } void AttackState::update(Guard& g, float dt) { // 省略伤害计算，只演示状态流转 } void AttackState::onEvent(Guard& g, GuardEvent e) { if (e == GuardEvent::LeaveRange) { std::cout << "[Attack] 敌人脱离射程，回到警戒" << std::endl; g.changeState(AlertState::instance()); } else if (e == GuardEvent::HealthLow) { std::cout << "[Attack] 血量过低，逃跑" << std::endl; g.changeState(FleeState::instance()); } } void FleeState::onEnter(Guard& g) { std::cout << "[Flee] 开始撤退" << std::endl; } void FleeState::update(Guard& g, float dt) { // 撤退回血逻辑省略 } void FleeState::onEvent(Guard& g, GuardEvent e) { if (e == GuardEvent::EnemyLost) { std::cout << "[Flee] 成功摆脱敌人，回到巡逻" << std::endl; g.changeState(PatrolState::instance()); } }main 函数里跑一次：
int main() { Guard guard; guard.update(1.0f); guard.handleEvent(GuardEvent::SpottedEnemy); guard.handleEvent(GuardEvent::EnterRange); guard.update(1.0f); guard.handleEvent(GuardEvent::HealthLow); guard.handleEvent(GuardEvent::EnemyLost); return 0; }输出会依次是：巡逻、发现敌人、警戒、进入射程、攻击、血量过低、逃跑、摆脱敌人、巡逻。整个流转过程里，状态对象没有一次new，没有一次delete，切换只是指针赋值，并且commitPendingState保证了每个状态方法返回后才真正替换当前状态。这种轻量方式在游戏客户端里跑一整场对局几乎没有额外开销。
6.3 从这套精简实现里得到的实测结论
我自己在实际项目里迭代过好几次状态模式，最大的体会是：初期的痛点大多不是“怎么写状态类”，而是“状态对象的所有权”和“数据共享方式”没想清楚。静态实例加裸指针能解决绝大多数无数据状态；带私有数据的状态就用延迟提交加unique_ptr；跨状态共享的数据一律抬高到上下文。把这三条决策做完，状态模式在 C++ 里的落地就会顺畅很多。
另外一个容易忽略的小细节是：进入新状态时最好统一走onEnter，不要在构造函数里做初始化。因为静态实例模式下构造函数只执行一次，而状态切换是无数次；把“每次进入状态要做的动作”写进onEnter，才能保证切回同一个状态时逻辑正确。我用这个守卫 AI 的例子调试时，一开始把“打印进入攻击”放在了AttackState构造函数里，结果第二次进入攻击状态完全没有输出，才意识到这个问题。
这套精简实现让我觉得，状态模式的核心其实不是消灭 if-else，而是把“会变的那部分”放在你能看见、能修改、能单独测试的地方。如果你也正在设计一个状态多变的功能，希望这些细节能帮你少走一段弯路。
