C++状态模式实战：从if/else地狱到优雅状态机

做C++这几年，我发现自己最常写的代码不是算法，而是各种状态切换。游戏角色要待机、走路、攻击、死亡，网络连接要连接中、已连接、重连、断开，连协议解析都要按状态读字节。最早的时候我习惯写 if (state == ...) else if ...，状态少还好，一多起来简直就是灾难。后来用状态模式把这堆逻辑拆开，代码一下子清爽了。这篇文章就从实际项目出发，聊聊C++里状态模式怎么设计、怎么写、怎么避开常见的坑。如果你也在为状态切换头疼，或者准备面试时被问状态模式和策略模式的区别，这篇应该能帮到你。

1. 从一把梭到状态模式：先理解它解决什么问题

1.1 if/else 的地狱，你真的忍得了吗

很多C++项目一开始状态切换都是这么写的：根据一个 state_ 枚举变量，在 update() 里写一长串分支。我说一个最常见的游戏角色例子，角色有 Idle、Running、Attack、Hurt、Dead 这几种状态，每个状态里要做的事都不一样，比如 Idle 要回蓝，Running 要消耗体力，Attack 要生成攻击判定，Hurt 要播放受击动画，Dead 要释放资源。如果把这五个状态都堆在一个 update() 里，你得到的大概是这样的东西：

cpp复制if (state_ == Idle) {
    // 回蓝、播放待机动画、检测周围敌人
} else if (state_ == Running) {
    // 移动、消耗体力、播放跑步动画
} else if (state_ == Attack) {
    // 生成攻击判定、播放攻击动画
    if (attackDone_) {
        state_ = Idle;
    }
} else if (state_ == Hurt) {
    // 播放受击动画、短暂硬直
} else if (state_ == Dead) {
    // 释放技能资源、播放死亡动画
}

这个代码在只有5个状态时还能忍，但等你加上技能、闪避、格挡、跳跃、疾跑之后，一个 update() 能到两三百行。更麻烦的是，状态和状态之间还有复杂的迁移条件。比如“攻击”状态在受到伤害时应该进入“硬直”，但“硬直”完了回到“攻击”还是“待机”又取决于当前攻击段数。这些条件混在 if/else 里，后期加一个状态就得把所有的分支都过一遍，漏一个就是线上 bug。

状态模式的思路很简单：别把状态当成一个变量来 switch，而是把每个状态当成一个类，把“这个状态下该干什么”和“从这个状态能切到哪些状态”都封装到类里。上下文只保存一个“当前状态”的指针，每次调用 update 就把工作委托给当前状态对象。这样新增状态时就多写一个新类，不用去动原来那一大坨 if/else。本质上就是把变化隔离，让每个状态自己管理自己。

1.2 状态模式的三个核心角色

状态模式不是玄学，它的核心角色就三个：

• Context（上下文）：持有一个当前状态对象，对外暴露 SetState()、HandleInput()、Update() 等接口。所有外部请求都转发给当前状态。
• State（状态抽象）：定义状态行为接口，在C++里一般是一个抽象基类，包含 Enter()、Update()、Exit() 等虚函数。
• ConcreteState（具体状态）：实现每个状态的具体行为以及状态迁移逻辑。

我用一个很生活化的例子类比：你把电视遥控器当成 Context，遥控器里的“当前频道模式”就是状态对象。你按下“音量+”按钮时，遥控器不关心你在看新闻还是综艺，它只是把按键事件转发给当前的频道状态，由那个状态去调整音量或者切换输入源。是不是比在遥控器里写 if (channelMode == TV) ... else if (channelMode == HDMI) ... 清爽多了？

说回C++，这三个角色的接口可以长这样：

cpp复制class Character;

class State {
public:
    virtual ~State() = default;

    virtual void Enter(Character& character) = 0;
    virtual void Update(Character& character, float dt) = 0;
    virtual void Exit(Character& character) = 0;
};

Character 是上下文，它负责持有 unique_ptr<State> currentState_，并在 ChangeState() 里完成“退出旧状态、进入新状态”的时序控制。后面的代码示例里我会完整写一遍，这里先记住一个关键点：状态的切换动作不是 Context 内部一个 switch，而是由具体状态在合适的时机调用 context.ChangeState(std::make_unique<NewState>())。

2. 实战落地：用C++写一个角色状态机

2.1 先定义场景：游戏角色状态切换

为了不空谈理论，我挑一个特别常见的游戏场景：横版动作游戏角色。角色有四种状态：Idle（待机）、Running（跑动）、Attack（攻击）、Hurt（受击）。这里先不引入死亡，因为死亡状态往往需要额外处理资源释放，单独拿一节讲。

状态的切换规则如下：

看到没有，最复杂的不是单个状态里的逻辑，而是状态之间这十几个迁移关系。用 if/else 写，你至少得有七八个 if (state_ == X && event == Y) 的判断；用状态模式写，每个状态类只需要关心自己能迁到哪几个状态。

2.2 抽象状态接口怎么写

先给上下文 Character 一个声明。因为状态类要调用 ChangeState，而 Character 要调用状态类的方法，二者天然互相引用。为了避免循环包含，我在头文件里先用前置声明：

cpp复制// Character.h
class State;

class Character {
public:
    enum class Input { None, PressLeft, PressRight, ReleaseAxis, PressAttack, TakeDamage };

    Character();
    void Update(float dt);
    void HandleInput(Input input);

    void ChangeState(std::unique_ptr<State> nextState);
    void OnAttackAnimationFinished();

private:
    std::unique_ptr<State> currentState_;
    float hp_;
};

State 接口设计中，我一般会加三个虚函数：Enter 在进入状态时调用一次，适合做初始化，比如进入 Attack 时设置攻击判定；Update 每帧调用，做持续逻辑；Exit 在离开状态时调用，适合清理资源，比如退出 Attack 时销毁攻击判定。

cpp复制// State.h
class Character;

class State {
public:
    virtual ~State() = default;
    virtual void Enter(Character& character) = 0;
    virtual void Update(Character& character, float dt) = 0;
    virtual void Exit(Character& character) = 0;
};

这里要注意一点：Exit 不是析构函数。离开状态不等于销毁状态对象，因为状态对象可能被缓存复用，或者在 ChangeState 里先 Exit 再析构。把清理工作放在 Exit 里，才能真正控制“切换的瞬间发生了什么”。

2.3 具体状态类示范

下面我写一个 IdleState 和一个 RunningState，代码量不大，但足够展示状态模式怎么消除分支。

cpp复制// IdleState.h
class IdleState : public State {
public:
    void Enter(Character& character) override;
    void Update(Character& character, float dt) override;
    void Exit(Character& character) override;
};

实现文件里，IdleState::Update 就不再是一大段 if else，而是只关心“当前状态下可能发生什么”。

cpp复制// IdleState.cpp
#include "IdleState.h"
#include "RunningState.h"
#include "AttackState.h"
#include "HurtState.h"
#include "Character.h"

void IdleState::Enter(Character& character) {
    character.SetAnimation("idle");
}

void IdleState::Update(Character& character, float dt) {
    auto input = character.ReadInput();

    if (input.HasHorizontalAxis()) {
        character.ChangeState(std::make_unique<RunningState>());
    } else if (input.WasAttackPressed()) {
        character.ChangeState(std::make_unique<AttackState>());
    } else if (input.WasDamageTaken()) {
        character.ChangeState(std::make_unique<HurtState>());
    }
}

void IdleState::Exit(Character& character) {
    // 待机状态一般没有需要手动释放的资源
}

RunningState 类似，只是切换条件变成了“水平轴归零回 Idle”，“按攻击进 Attack”，“受击进 Hurt”。

cpp复制void RunningState::Update(Character& character, float dt) {
    character.MoveByAxis(dt);
    auto input = character.ReadInput();

    if (!input.HasHorizontalAxis()) {
        character.ChangeState(std::make_unique<IdleState>());
    } else if (input.WasAttackPressed()) {
        character.ChangeState(std::make_unique<AttackState>());
    } else if (input.WasDamageTaken()) {
        character.ChangeState(std::make_unique<HurtState>());
    }
}

Character::ChangeState 的实现就非常关键了，它负责统一处理旧状态的退出和新状态的进入：

cpp复制void Character::ChangeState(std::unique_ptr<State> nextState) {
    if (currentState_) {
        currentState_->Exit(*this);
    }
    currentState_ = std::move(nextState);
    currentState_->Enter(*this);
}

有人可能觉得状态模式代码变多了，确实，一个状态就要一个类。但换来的是：新增“闪避”状态时，你只要写一个 DodgeState，并且在 IdleState、RunningState、AttackState 里各加一个迁移分支，原来几百行的 switch 完全不用动。这在状态数量超过5个后，收益会非常明显。

3. C++状态模式的实现细节与性能取舍

3.1 智能指针 vs 裸指针

C++ 写状态模式最常见的坑就是内存管理。状态对象什么时候创建、什么时候销毁、切换时会不会泄漏，新手很容易搞错。

我的建议是：上下文统一用 std::unique_ptr<State> 持有当前状态。每次 ChangeState 都是 std::make_unique<NewState>() 创建新对象，再把旧对象替换掉。这样 unique_ptr 的析构会自动清理旧状态，不需要手动 delete。

cpp复制void Character::ChangeState(std::unique_ptr<State> nextState) {
    // 先退出旧状态，保证清理逻辑执行
    if (currentState_) {
        currentState_->Exit(*this);
    }
    // 再替换，unique_ptr 会自动 delete 旧状态对象
    currentState_ = std::move(nextState);
    // 最后进入新状态
    currentState_->Enter(*this);
}

这里有一个关键点：Exit 调用时，currentState_ 还指向旧状态对象，这个对象在 std::move 之后才被析构。所以你在 Exit 里引用的资源在那一瞬间仍然有效，不会出现“资源已经被销毁才执行清理”的越界错误。

如果你的状态类本身不携带实例数据，只有行为，那每个状态其实只需要一个实例，可以使用单例模式或者静态对象，切换的时候只换指针不换对象：

cpp复制class IdleState : public State {
public:
    static IdleState& Instance() {
        static IdleState instance;
        return instance;
    }
    // 不用 override Enter/Exit 里的实例字段
};

void Character::ChangeState(State& nextState) {
    if (currentState_) {
        currentState_->Exit(*this);
    }
    currentState_ = &nextState;
    currentState_->Enter(*this);
}

但要注意，单例状态意味着所有 Character 实例共享同一个状态对象。如果状态对象里存了“攻击段数”“剩余硬直时间”之类的实例数据，那就不能单例，必须每次创建独立对象。我踩过这个坑：早期图省事用单例，结果两个角色共用一个 AttackState，攻击段数互相污染，后来改成每次 make_unique 才解决。

3.2 虚函数调用与性能取舍

C++多态天然会引入虚函数表查表开销。有些对性能敏感的项目会担心状态模式每帧调用虚函数太慢。我的看法是：绝大多数场景下，这个开销可以忽略不计。一次虚函数调用就是几个周期的事，而你一个 update() 里可能光状态逻辑就有几百上千条指令，占比很小。

真正需要担心的不是虚函数开销，而是状态切换频率。如果状态切换非常高频，比如每帧切换几十万次，那么 std::make_unique 的堆分配可能成为瓶颈。这时可以换两种思路：

第一种是枚举 + switch。状态数量不多时，直接用 enum class StateType 加一个 switch 分支，性能最高，代码也不是很难看。我之前做过一个嵌入式网络协议解析器，状态只有4个，状态迁移都是字节级操作，我就直接用枚举加 switch，省了堆分配，代码运行非常稳定。

第二种是状态表驱动。把状态迁移关系抽象成一张表：

cpp复制struct Transition {
    int currentState;
    int event;
    int nextState;
};

const std::vector<Transition> kTransitionTable = {
    {StateType::Idle, Event::Move, StateType::Running},
    {StateType::Idle, Event::Attack, StateType::Attack},
    // ...
};

查表完成转移，没有虚函数，也没有堆分配，内存还连续，适合嵌入式或者游戏服务器热路径。缺点是状态里的“行为”还是得靠 switch 或者函数指针表去分派，代码结构比状态模式略散。所以我的选择标准是：状态数量少但行为多 -> 状态模式；状态数量多但行为简单 -> 状态表驱动；状态数量少且行为简单 -> 枚举+switch。

3.3 现代C++的std::variant状态机

如果你用 C++17 或以上版本，还有一个非常优雅的写法：用 std::variant 替代多态状态类。这种写法没有堆分配，没有虚函数，完全是值类型，性能高且直观。

先定义每个状态的结构体，它们不再继承接口，而是通过重载访问分别处理：

cpp复制struct IdleState {
    void Update(Character& character, float dt) { /* ... */ }
};

struct RunningState {
    void Update(Character& character, float dt) { /* ... */ }
};

struct AttackState {
    void Update(Character& character, float dt) { /* ... */ }
};

using CharacterState = std::variant<IdleState, RunningState, AttackState>;

然后定义一组访问器，用 std::visit 统一调用。C++17 的 std::overloaded 写法：

cpp复制template<class... Ts> struct overloaded : Ts... { using Ts::operator()...; };
template<class... Ts> overloaded(Ts...) -> overloaded<Ts...>;

class Character {
public:
    void Update(float dt) {
        std::visit(overloaded{
            [](IdleState& s, float dt) { /* idle update */ },
            [](RunningState& s, float dt) { /* running update */ },
            [](AttackState& s, float dt) { /* attack update */ }
        }, currentState_, dt);
    }

    CharacterState currentState_;
};

这里的优势是 currentState_ 直接在栈上，不存在 new/delete，也不会因为状态生命周期管理出错导致崩溃。缺点也很明显：状态切换变成了 currentState_ = RunningState{}，但如果你想在切换时执行 Exit/Enter 逻辑，需要额外在赋值前后处理，没有虚函数版本那么直观。所以我更推荐在嵌入式、游戏服务器这种对分配敏感但状态迁移相对简单的项目里用 variant，而在业务逻辑复杂、状态类经常扩展的项目里用经典多态。

4. 状态模式实战中的坑与排查技巧

4.1 状态切换的时序问题

状态模式最常见的运行时崩溃来自切换时序。看这段伪代码：

cpp复制void AttackState::Update(Character& character, float dt) {
    // 攻击动画结束了，切回待机
    if (character.IsAttackAnimationDone()) {
        character.ChangeState(std::make_unique<IdleState>());
    }
}

看起来没问题，但如果 Character::ChangeState 里先 Exit 旧状态再 Enter 新状态，而 AttackState::Exit 里又访问了 AttackState 自己的成员，就有可能出现“对象还被使用，但已经准备被销毁”的状态。别慌，只要你把 Exit 调用放在 std::move(nextState) 之前，旧状态对象在 Exit 执行那一刻还是活着的，不会出问题。真正要小心的是不要在 Exit 里再次调用 ChangeState，这样会递归触发 Exit，容易把状态机搞成无限循环。

我遇到过一个真实 bug：角色在受击硬直结束的瞬间被另一发攻击命中，HurtState::Update 里检查硬直结束，准备切回 Idle，但同一帧又来了一次伤害事件，逻辑里又尝试切到新的 HurtState。两个 ChangeState 叠加，最后状态机的当前状态变成了 Idle，但 HurtState::Exit 里释放的受击特效没有被触发，画面表现异常。

解决方案是在状态机入口加一个延迟切换队列：如果状态正在切换中，先记录请求，等当前切换完成后再处理下一个。具体实现可以给 Character 加一个 pendingState_：

cpp复制void Character::ChangeState(std::unique_ptr<State> nextState) {
    if (isSwitching_) {
        pendingState_ = std::move(nextState);
        return;
    }
    DoChangeState(std::move(nextState));
}

void Character::DoChangeState(std::unique_ptr<State> nextState) {
    isSwitching_ = true;
    if (currentState_) {
        currentState_->Exit(*this);
    }
    currentState_ = std::move(nextState);
    currentState_->Enter(*this);
    isSwitching_ = false;

    if (pendingState_) {
        auto state = std::move(pendingState_);
        pendingState_.reset();
        ChangeState(std::move(state));
    }
}

这个模式看起来很朴素，但在游戏和网络状态机里非常实用，能避免很多“同一帧多次切换”引发的时序灾难。

4.2 状态模式 vs 策略模式，别再搞混

面试 C++ 岗位时，“状态模式和策略模式的区别”几乎是八股文钉子户。我见过不少人把两个模式说成一回事，因为它们结构确实很像：都是定义抽象接口、具体实现类、上下文持有其中一个对象。但职责完全不同。

策略模式的核心是**“封装修法，客户端选择算法”**。比如排序策略、压缩策略，客户端在运行前决定用哪种算法，之后一般不会再改，即使改也是由客户端显式触发。策略模式不做“自动迁移”，策略之间没有内在的状态依赖。

状态模式的核心是**“封装状态相关行为，状态自己决定迁移”**。上下文内部的状态对象会在运行时主动发起切换，用户只看到最终行为的变化，不需要参与判断。比如角色受到攻击时，HurtState 自动接管，这个迁移过程是状态机内部的规则。

一句话区别：策略是面向算法族的封装，状态是面向状态机的封装；策略的切换由外部决定，状态的切换由内部驱动。

这个区别在代码里也很明显：策略模式的 Context 暴露 SetStrategy() 给外部调用；状态模式的 Context 暴露 ChangeState() 但通常只有状态对象自己会调用。你把两者混淆，设计出来的系统就容易出现“状态对象被外部随意切换，导致状态机规则失控”的问题。

4.3 调试与测试状态机

状态机一旦出 bug，最常见的表现是“角色突然瞬移”“技能放不出来”“网络连接卡在某个状态”。我调试状态机的三板斧：

第一，状态切换日志。在 Character::DoChangeState 里打一行日志，记录从哪个状态切到哪个状态，以及触发原因：

cpp复制void Character::DoChangeState(std::unique_ptr<State> nextState) {
    // 日志需要 stateName()，每个状态类提供静态方法
    std::cout << "[State] " << currentStateName_ << " -> " << nextState->Name()
              << std::endl;
    // ...
}

注意 nextState 在 std::move 之后不能再取名字，所以要在 std::move 之前先取 Name()。

第二，禁止状态被重复进入。有些状态比如 Dead 应该只能进入一次，如果重复进入说明迁移条件有误。可以在 ChangeState 里做一个判断：

cpp复制if (currentState_ && typeid(*currentState_) == typeid(*nextState)) {
    return; // 同一状态不重复切换
}

但要注意，有些场景下“重新进入同一状态”是合法的，比如攻击取消再攻击，想重置攻击段数。这时你可以加一个 force 参数：默认不重复进入，主动传 true 才允许。

第三，写状态迁移表测试。把状态迁移规则整理成一张表，用单元测试跑一遍每个 (state, event) 组合的期望结果。我用过 GoogleTest，也用过裸 assert，思路都一样：

cpp复制void test_transition_idle_on_move() {
    Character c;
    c.HandleInput(Input::Move);
    assert(c.GetCurrentStateName() == "Running");
}

这种测试一旦跑起来，状态机回归就特别稳。我曾经在改造一个网络协议状态机时，把全部迁移规则写成测试用例，跑了两个小时就把新增状态带来的问题全揪出来了。

5. 在VS Code中配置C++状态机开发环境（实操笔记）

5.1 快速搭一个可运行的C++项目

状态模式代码写起来很简单，但很多刚开始学C++的朋友会卡在环境上。这里分享一下我现在最常用的 VS Code 配置方式，很适合跑状态模式这种单文件多文件的小项目。

首先，确保你装了编译器。Windows 推荐用 MinGW-w64，Linux 直接用自带的 g++。在终端里验证：

bash复制g++ --version

然后在 VS Code 里安装两个扩展：C/C++（ms-vscode.cpptools）和 CMake Tools。后者不是必须的，但装上之后管理多文件项目会省心很多。

配置 tasks.json 时，最简单的方案是直接写编译命令：

json复制{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "build state machine",
            "type": "shell",
            "command": "g++",
            "args": [
                "-std=c++17",
                "-g",
                "src/*.cpp",
                "-Iinclude",
                "-o",
                "bin/main"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            }
        }
    ]
}

这个任务会编译 src 目录下所有 .cpp 文件，头文件在 include 目录。你只需要按 Ctrl+Shift+B 就能编译。要注意 bin 目录要提前建好，否则 g++ 会报“No such file or directory”。

5.2 用CMake管理状态机代码

如果项目文件多了，或者要跨平台编译，我建议直接用 CMake。我写状态机项目时通常用这版 CMakeLists.txt，够用也不复杂：

cmake复制cmake_minimum_required(VERSION 3.16)
project(StateMachineExample)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

add_executable(main
    src/main.cpp
    src/Character.cpp
    src/IdleState.cpp
    src/RunningState.cpp
    src/AttackState.cpp
)

target_include_directories(main PRIVATE include)

在 VS Code 里装好 CMake Tools 扩展后，打开这个目录，扩展会自动识别 CMakeLists.txt。你只需要按 F7 就能构建，按 F5 就能调试。调试状态机时，学会用断点看 currentState_ 的指针指向哪个具体状态，比打日志还要直接。

有个小坑：如果你从网上下载了一些旧版 C++ 代码，编译器默认可能用的是 C++14，导致 std::variant 或者 std::make_unique 编译报错。记得在 tasks.json 或者 CMake 里显式指定 -std=c++17。

5.3 把状态模式扩展到真实项目

状态模式不只是游戏角色的专利，在真实工程里，最常见的是网络协议状态机。比如一个 TCP 客户端的连接状态有 Closed、Connecting、Established、Reconnecting、Disconnected。每个状态处理的事件不同：

cpp复制class ConnectingState : public State {
public:
    void Update(NetworkConnection& conn, float dt) override {
        if (conn.IsConnected()) {
            conn.ChangeState(std::make_unique<EstablishedState>());
        } else if (conn.IsTimeout()) {
            conn.ChangeState(std::make_unique<ReconnectingState>());
        }
    }
};

这个场景和角色状态机几乎一模一样，只是上下文从 Character 变成了 NetworkConnection，状态里存的从 hp_ 变成了 socket_。

再进一步，如果状态机运行在多线程环境，需要注意状态切换和事件处理的线程安全。我习惯用“事件队列 + 单线程状态机”的方式：外部线程只往队列里塞事件，状态机线程从队列里取事件执行迁移，这样状态切换本身不需要加锁。如果必须在状态机内部加锁，也要注意不要在同一把锁内调用 ChangeState，否则容易死锁。

我在做物流网络模拟时还用过状态机做任务流转：每个包裹从 等待发货 -> 运输中 -> 派送中 -> 已签收。因为是模拟系统，状态切换频率不高，用状态模式非常清晰，每个包裹只要维护一个状态对象指针，后续加“退件”“异常滞留”状态只需新增状态类，原有的状态逻辑完全不用动。这也是状态模式能让人“减负”的本质：把复杂度从控制流里剥离，塞进一个个边界清晰的状态类里。

最后再分享一个小技巧：不管你的状态类是用多态还是 std::variant，一定要给每个状态定义一个稳定的字符串名字。调试日志、错误上报、UI 状态显示都靠它。名字统一了，后面所有排查工具都会好写很多。我用这个习惯在几个项目里都省下了大量排查时间。