C++状态模式实战：从虚函数到std::variant的状态机重构

状态模式这词，很多C++程序员第一反应是“设计模式里那个画起来挺麻烦的东西”，接着就是“我写业务代码这么多年，好像也没真正用过”。但你真去做网络协议栈、游戏角色AI、嵌入式设备状态切换这类项目，很快就会撞上一堵墙：代码里密密麻麻全是if-else，加一个新状态要翻半天，测试用例堆成山，还动不动就在某个分支里改出另一个状态的bug。

我最近重构一个设备控制模块时把状态机从switch-case改成了状态模式，整个模块的行为逻辑清晰了一大截。这篇就用自己的实战经历，把状态模式在C++里怎么设计、怎么实现、有哪些坑，一次性讲透。

1. 为什么状态模式是C++项目里的“隐藏刚需”

先说个场景：你在维护一个老项目，里面有个通信模块，要处理空闲、连接中、已连接、重连等待、断开这几个状态。最初的代码很“直白”，一个enum加一个巨大的switch，每个事件进来都先判断当前状态，再决定要不要处理。

enum class ConnState { Idle, Connecting, Connected, Reconnecting, Disconnected }; void handleEvent(ConnState& state, Event event) { switch (state) { case ConnState::Idle: if (event == Event::ConnectRequest) { initSocket(); state = ConnState::Connecting; } break; case ConnState::Connecting: if (event == Event::ConnectSuccess) { registerHeartbeat(); state = ConnState::Connected; } else if (event == Event::ConnectTimeout) { scheduleRetry(); state = ConnState::Reconnecting; } break; // 每个case还要继续堆... } }

这种写法前三个状态还凑合，等你加上重连、半关闭、鉴权、心跳超时踢线，这个函数就开始失控。每个分支里既要做状态迁移，又要执行动作，还要处理异常路径，状态多了以后你根本不敢随便动它——因为一个case内部改了某个变量，可能影响另一个case的判断逻辑。更麻烦的是，你没法一眼看出来“哪个状态允许哪个事件”，状态之间的流转关系全藏在代码深处。

状态模式做的事情，本质上就是把这堆散落的逻辑“按状态封装起来”。每个状态对应一个类，类里面只处理自己关心的事件，状态之间通过上下文对象做迁移。这样带来的直接好处有三个：

• 新加一个状态，只需要新写一个类，不用回头改已有的状态类。
• 每个状态的进入、退出、事件处理逻辑内聚在同一个类里，排查问题目标明确。
• 状态迁移关系变得显式，代码结构本身就成了文档。

我自己做完这个重构后有个体会：状态模式不是用来“炫技”的，它是在状态数量超过4个、事件种类超过3种时，控制复杂度的实用工具。你要是只有两三个状态，if-else完全没问题，别硬套模式。

2. 经典版实现：抽象基类加虚函数的状态机骨架

先看最正统、也是最好理解的方案：用一个抽象状态基类定义事件处理接口，每个具体状态继承并实现自己关心的逻辑，上下文类持有当前状态指针，负责转发事件和切换状态。

2.1 状态基类与上下文类的核心设计

状态基类的接口设计是关键。最忌讳的是把所有事件都塞进一个handle(Event)泛化方法里，那样又回到switch的老路。正确做法是“每个事件一个虚函数”，这样编译器能帮你检查——某个状态忘了实现某事件，至少类型系统是完整的。

// 前向声明，避免循环依赖 class Connection; class ConnectionState { public: virtual ~ConnectionState() = default; // 每个事件对应一个虚函数，默认行为是“忽略” virtual void onConnectRequest(Connection& ctx) {} virtual void onConnectSuccess(Connection& ctx) {} virtual void onConnectTimeout(Connection& ctx) {} virtual void onDisconnect(Connection& ctx) {} virtual void onHeartbeatTimeout(Connection& ctx) {} virtual void enter(Connection& ctx) {} virtual void exit(Connection& ctx) {} protected: // 子类可以通过这个辅助方法做状态迁移 void transitionTo(Connection& ctx, ConnectionState* nextState); };

这个设计的精髓在默认空实现上。状态机里有个常见场景：某状态收到一个它不关心的事件，比如正在连接中收到重复的连接请求，这时候最合理的动作是什么都不做。如果没有默认空实现，每个状态类都要写一堆空函数，代码会很啰嗦；有了空实现，子类只需要覆盖自己关心的那一个两个函数，头脑负担小很多。

transitionTo通常由上下文类提供，状态对象需要在迁移时拿到上下文引用。这里有个很微妙的点：状态迁移动作放在状态类内部，还是由上下文类控制？我倾向于由上下文类暴露一个changeState方法，状态类通过传入的上下文引用来调用。这样状态类之间不会直接互相依赖，迁移动作统一收敛在上下文里，方便加日志和断点。

2.2 上下文对象如何管理状态切换

上下文类是状态机的心脏。它持有当前状态指针、维护状态栈（如果需要的话）、向外部调用方提供统一的业务接口。

class Connection { public: Connection() : m_state(&IdleState::instance()) { m_state->enter(*this); } // 对外的业务方法，内部转发给当前状态 void sendData(const std::string& data) { if (m_state) { m_state->onSendData(*this, data); } else { std::cerr << "No state!" << std::endl; } } void connectRequest() { m_state->onConnectRequest(*this); } void changeState(ConnectionState* nextState) { if (nextState == m_state) { return; } if (m_state) { m_state->exit(*this); } m_state = nextState; if (m_state) { m_state->enter(*this); } } // 状态类需要访问的业务数据 Socket& socket() { return m_socket; } Timer& timer() { return m_timer; } private: ConnectionState* m_state; Socket m_socket; Timer m_timer; };

这里我用了“单例状态”的做法：IdleState::instance()。纯状态对象的成员变量极少，通常只有配置或者日志引用，所以可以做成单例复用。这个细节很重要——如果每个迁移都new一个新状态对象，就得处理delete旧对象的问题，还要担心迁移和析构的时序。单例直接绕开了生命周期管理，状态对象本身不持有动态资源，安全又省心。

外部调用方完全不知道状态机的存在。它只看到Connection::connectRequest()、Connection::sendData()这一层业务接口。状态机内部怎么流转、现在处于什么状态，对外部不可见。这个封装是状态模式的一个核心收益：状态的复杂性被包在类内部，调用方的心智模型是“这个连接对象能干什么”，而不是“当前状态是什么”。

2.3 具体状态类的写法示例

以空闲状态为例，它只关心两个事件：收到连接请求就发起连接，其他事件一律忽略。

class IdleState : public ConnectionState { public: static IdleState& instance() { static IdleState inst; return inst; } void onConnectRequest(Connection& ctx) override { std::cout << "[Idle] connect request received, start connecting...\n"; ctx.socket().beginConnect(); transitionTo(ctx, ConnectingState::instance()); } void enter(Connection& ctx) override { ctx.socket().close(); ctx.timer().cancelAll(); } private: IdleState() = default; };

通过transitionTo迁移到ConnectingState::instance()，状态切换的过程发生在上下文类内部。每个状态类只做一件事：进来的时候需要做什么准备、收到什么事件做什么动作、走的时候需要清理什么。我把业务动作写在事件函数里，清理动作放在exit里，初始化放在enter里，这样状态切换的副作用是可控的。

这套骨架看起来简单，真实项目里跑起来才会体会到它的好：你加一个“数据重传中”状态，只需要新写一个类，迁移到它的地方加一行代码，不需要动其他类。改了一个状态的内部逻辑，影响的边界被类墙隔开，测试时也更容易构造“只处于某个状态”的单元测试。

3. 现代C++方案：用std::variant去掉继承

经典方案有几处不太现代的地方。第一，用裸指针管理状态，虽然单例避免了delete问题，但类型上还是不干净。第二，状态之间依赖具体类，比如IdleState直接引用了ConnectingState::instance()，迁移关系硬编码，改动时需要编译很多文件。第三，虚函数调用虽说不慢，但在某些超高频事件流控场景里，多一次间接跳转也会成为压测时的关注点。

C++17之后，std::variant提供了一种完全不同的组织方式：把状态作为一个可辨识联合体存起来，状态间的迁移通过std::visit来派发。不需要虚函数，不需要继承，状态对象就是普通的struct。

3.1 为什么可以用variant替代虚函数

核心思路变化：虚函数方案是“每个状态类内部处理同一组事件”，variant方案是“把所有状态类列举成一个类型集合，状态机持有当前是哪个类型，事件处理用访问者模式展开”。

struct IdleState { void onConnectRequest(Connection& ctx); }; struct ConnectingState { void onConnectSuccess(Connection& ctx); void onConnectTimeout(Connection& ctx); void onDisconnect(Connection& ctx); }; struct ConnectedState { void onDisconnect(Connection& ctx); void onHeartbeatTimeout(Connection& ctx); }; using ConnStateVariant = std::variant<IdleState, ConnectingState, ConnectedState>;

状态机的键是std::variant<IdleState, ConnectingState, ConnectedState>，也就是当前状态一定是其中一个类型。事件到达时用std::visit对一个重载了operator()的访问者进行调用，在编译期就确定要执行哪个状态的哪个逻辑，运行期没有任何虚函数跳转。

这个方案最打动我的一点是：迁移时天然需要“换一个状态”，而variant的emplace<NextState>()操作非常便宜，不涉及动态分配。状态对象可以是纯值语义，拷贝、赋值、移动都规规矩矩，调试起来很舒服。

3.2 std::visit派发与状态迁移实现

先看事件处理的写法。以一个通用的访问者为例：

template<typename... Ts> struct overloaded : Ts... { using Ts::operator()...; }; template<typename... Ts> overloaded(Ts...) -> overloaded<Ts...>; class Connection { public: void handleConnectSuccess() { std::visit(overloaded{ [&](ConnectingState& state) { state.onConnectSuccess(*this); }, [&](auto& state) { // 默认：其它状态不处理这个事件 logStateDropped("ConnectSuccess", state); } }, m_state); } private: ConnStateVariant m_state; };

overloaded这个惯用法是聚合多个lambda成为访问者，C++20里可以直接用，C++17需要配一个推导指引。它很巧妙地处理了“默认忽略”的语义：针对ConnectingState写一个专门的重载，再写一个auto&的通用重载，其它状态进来什么都不做。如果你不想用模板，也可以把所有状态都列全，每个写一行，代码更直白。

状态迁移在这里反而比虚函数版本还简洁：

void ConnStateVariantHolder::transitionToConnected() { m_state.emplace<ConnectedState>(); }

不需要记住changeState内部先exit再enter的顺序，因为variant的emplace就是构造新对象并析构旧对象，而每个状态对象的构造函数和析构函数天然承担了进入和退出的职责。这里我要强调一个实践差异：虚函数方案里最好把初始化放enter、清理放exit，但variant方案里它们就对应构造和析构函数。如果你之前是纯C风格状态机转过来的，一开始会不习惯把状态对象当真正的对象用，但实际上这个设计更符合RAII习惯——状态对象的生命周期由variant管理，异常安全也更好。

每个状态struct内部可以直接持有属于该状态的数据。比如ConnectedState里放一个心跳计数器、一个重发队列的索引，这些数据随状态进入而构造、随状态退出而析构，不会泄漏到其他状态里面。这在虚函数单例方案里是做不到的——单例共享同一份成员，很容易出现跨状态的数据残影。

3.3 两种方案的适用边界对比

很多文章把虚函数版和variant版对立起来，好像非要分个高下。我自己的经验是它们各自有适用场景：

我的建议很简单：如果你只想让状态机代码更清晰、不追求极致性能，或者团队成员普遍不熟悉C++17模板技巧，经典虚函数版更稳妥。如果你的状态之间需要携带大量中间数据，或者状态机的状态集合相对固定、事件处理频率极高，variant版更符合现代C++的代码习惯。我自己在两个项目里分别用了两种方案，虚函数版用在老代码维护、需要动态扩展策略的模块；variant版用在自研的协议栈，状态固定且性能敏感。两边都挺好用，关键在于别把两种风格混在一个状态机里。

4. 实战案例：用状态模式重构一个TCP连接状态机

眼见为实，我把整个重构过程按步骤展开。用一个简化但真实的TCP连接场景：初始化状态、正在连接、已连接、等待重连、已断开。除了连接/断开事件，还加上发送数据、心跳超时、重连计时器到期这些事件。这不只是套模式，还涉及状态迁移的约束、日志记录、异常处理，这些才是实际工程里最耗时间的部分。

4.1 梳理状态、事件与迁移矩阵

动手写代码之前，先把状态迁移关系写成表格。这一步极度重要，我见过太多人上来就写类，最后迁移关系一团乱麻。

这张表本身就是最顶层的设计文档。有了它，写代码时每个状态类只需要关注表格里自己所在的行，领域逻辑绝对不会绕晕。

我特别强调一下“已断开状态收到断开事件”这一行。看起来是无用分支，但真实系统里用户可能连续点击“断开连接”按钮。没有这个防护，状态机可能退到未知状态。状态模式里这行实现就是默认空实现，什么都不做，状态不变。这种“显式的忽略”和“忘记处理”是有本质区别的——前者是设计结果，后者是缺陷。

4.2 基于虚函数的状态类完整实现

因为我这个模块同时要跑在多个平台，编译期模板带来的二进制膨胀没法接受，所以我最后选了虚函数版本。下面直接贴核心代码，注释里写实现原因。

class Connection : public std::enable_shared_from_this<Connection> { public: using StatePtr = ConnectionState*; Connection(asio::io_context& io, const Endpoint& peer) : m_io(io), m_socket(io), m_peer(peer), m_state(&IdleState::instance()), m_retryCount(0) { m_state->enter(*this); } void setState(StatePtr next) { if (next == m_state) return; auto prev = m_state; if (prev) { prev->exit(*this); } m_state = next; m_state->enter(*this); std::cout << "[" << name() << "] state: " << prevName(prev) << " -> " << stateName(next) << std::endl; } // 对外接口 void startConnect() { m_state->handleStartConnect(*this); } void onConnected() { m_state->handleOnConnected(*this); } void onConnectTimeout() { m_state->handleOnConnectTimeout(*this); } void sendData(const char* data, size_t len) { m_state->handleSendData(*this, data, len); } void closeByUser() { m_state->handleClose(*this); } void retryTimerExpired() { m_state->handleRetryTimer(*this); } // 状态类要用的内部工具 void startAsyncConnect() { // 依赖具体网络库的实现 } void scheduleRetry() { ++m_retryCount; m_retryTimer.expires_after(std::chrono::seconds(1 << std::min(m_retryCount, 5))); m_retryTimer.async_wait([this](auto ec) { if (!ec) retryTimerExpired(); }); } void resetRetry() { m_retryCount = 0; } int retryCount() const { return m_retryCount; } std::string name() const { return m_name; } private: asio::io_context& m_io; asio::ip::tcp::socket m_socket; asio::steady_timer m_retryTimer; Endpoint m_peer; StatePtr m_state; int m_retryCount; std::string m_name; };

注意事件接口名我用的是handleXxx而不是onXxx，纯粹是个人习惯，强调这是“入口函数”。setState里的prevName和stateName是两个映射函数，用于日志输出，便于线上快速定位状态迁移链路。

再写连接中状态作为示例：

class ConnectingState : public ConnectionState { public: static ConnectingState& instance() { static ConnectingState inst; return inst; } void enter(Connection& ctx) override { ctx.startAsyncConnect(); std::cout << "[" << ctx.name() << "] entering connecting, timeout=5s\n"; } void exit(Connection& ctx) override { // 清理连接超时定时器 } void handleOnConnected(Connection& ctx) override { ctx.resetRetry(); ctx.setState(ConnectedState::instance()); } void handleOnConnectTimeout(Connection& ctx) override { if (ctx.retryCount() >= kMaxRetry) { ctx.setState(DisconnectedState::instance()); return; } ctx.scheduleRetry(); ctx.setState(ReconnectingState::instance()); } void handleClose(Connection& ctx) override { ctx.setState(IdleState::instance()); } private: ConnectingState() = default; };

这里有一个重要的设计取舍：连接超时后是进入“等待重连”还是直接“重连中”？状态表里我写的是等待重连，但代码里我用了ReconnectingState。在实际项目里，“等待重连”其实是一个带定时器的稳定状态，它不立刻发起连接，而是等定时器到期后在handleRetryTimer里迁移到连接中。连接中状态本身只负责“正在建立连接”这个短暂过程。这个区分看着琐碎，但它让每个状态的语义边界清楚了——连接中不持有重连策略数据，等待重连不持有socket连接逻辑，测试时能分别构造场景。

4.3 单元测试如何设计状态迁移

状态机重构后最大的受益方就是单元测试。原来的switch函数想测“连接超时后的重连行为”，你得构造一堆前置条件，非常痛苦；现在可以这样测：手动把状态机置于指定状态，直接调用事件函数，断言下一个状态。

TEST(ConnectionStateMachineTest, ConnectingTimeoutEntersReconnecting) { FakeConnection ctx; ctx.setState(ConnectingState::instance()); ctx.onConnectTimeout(); ASSERT_EQ(ctx.state(), ReconnectingState::instance()); } TEST(ConnectionStateMachineTest, ConnectedDisconnectGoesIdle) { FakeConnection ctx; ctx.setState(ConnectedState::instance()); ctx.closeByUser(); ASSERT_EQ(ctx.state(), IdleState::instance()); }

为了让状态机可测，我让ConnectionState的接口保持纯粹的事件转发，不依赖真实网络。上面测试里FakeConnection就是一个只实现状态机行为、不绑定asio套接字的测试替身。这也是状态模式的另一个红利：状态类依赖上下文接口，不依赖具体实现，你要换底层网络库时，业务状态迁移代码可以原封不动。

5. 各类实现方案的工程对比与性能实测

上面讲了两种C++实现，其实C风格的项目里还有一种“二维表+函数指针”的做法，很多嵌入式代码在用。它的思路是做一个状态/事件二维函数表，表格填上每个状态对应的处理函数指针。迁移动作也放表里，甚至可以直接用查表法驱动状态迁移。

5.1 三种方案放在一起看

函数表方案适合那些状态和事件都极其有限、行为可以完全用二维表格表达的嵌入式场景。你在Table里填一个{Idle, ConnectReq, StartConnect, Connecting}，执行时拿当前状态和事件去查表，命中就调用处理函数。这种方案的优点是数据驱动，肉眼能直接看到整个状态机的全貌；缺点是处理函数本身还是散落各地，状态多了以后表的维护本身就容易出错，没有编译器帮你检查漏填的格子。

5.2 虚函数 vs variant的实测数据

我在一个自研协议栈上做了一点微型基准测试：模拟10万次事件派发，对比虚函数版本和variant版本的耗时。测试场景刻意简单，只验证派发本身，不涉及业务逻辑。

• 虚函数版本：10万次派发耗时约1.0~1.2ms。
• std::variant版本：10万次派发耗时约0.3~0.5ms。
• 函数表版本：10万次派发耗时约0.25~0.4ms。

数据说明不了太多，毕竟业务处理一动就是几十上百微秒，派发的开销占比微乎其微。但如果你在流量每秒钟几万次的网关模块里面用状态机，这个差距确是实打实的。我平时选型更多看维护成本而不是这零点几毫秒，不过知道有差距，心里有个谱总是好的。

5.3 我的选型建议

如果项目已经用了C++17且状态集合不会频繁增删，优先variant；如果团队里有人不熟模板，或者要兼容老平台，虚函数版绝不丢人。

我在一个嵌入式设备项目里就用过函数表方案，状态少到只有五个，事件也固定，用表一眼看穿，比虚函数类舒服得多。而在另一个桌面工具里，状态多且每个状态的附属数据不一样，虚函数版反而是最平衡的选择。工具没有绝对好坏，配不上场景才是问题。

6. 状态模式实战中的坑与心得

最后分享几个我踩出来的经验。有些是机制问题，有些是设计习惯，提前知道可以少走很多弯路。

6.1 状态迁移与事件处理的时序陷阱

最容易踩的坑是“在迁移前调用了新状态才需要的方法”。比如连接成功的回调里，你以为新状态是已连接，于是直接在回调里调了ctx.sendData()，但此时ctx.m_state还指向连接中，sendData走到了连接中的空实现，什么也没发生。这种bug不报错，就是日志里一行诡异输出，排查起来非常费劲。

我的习惯：任何事件回调里，第一件事是通过状态类自身的函数做判断和迁移，迁移完成后立刻从上下文重新获取状态，再做后续业务。简单说就是“先迁移，后获取新状态，再使用新状态的能力”。另外，如果一个事件会触发连续迁移（比如A->B->C），一定要想清楚时序，别让B的exit动作在C已经构造后才被调用，不然清理逻辑交错，状态数据会互相污染。

6.2 状态类单例共享成员数据的隐患

虚函数版本里我用单例状态，有个前提就是状态类不能持有业务成员数据。有时候图方便，我在ConnectedState里加了一个int m_seq，用了很久没出事，直到一次高并发压测，两个连接共享同一个状态单例，m_seq互相覆盖，乱套了。

解决方式有两种：如果你的状态必须带数据，就不该用全项目单例，而是让上下文持有状态对象的所有权（每个上下文new一套），或者干脆把可变数据放到上下文对象里通过引用传递。我后来更倾向于“状态类只放不变量，可变数据放上下文”。这与状态模式的核心思路完全一致：切换的是行为，不是状态账单。

6.3 不要为了模式而模式，复杂度的临界点要清醒

状态模式不是银弹。状态数量少、事件简单的时候，直接if-else或者switch反而是最清晰的方案。我见过有人为了用状态模式，硬把三个状态拆成五个类，代码量翻倍，读起来绕一圈，团队review时怨声载道。

我自己的临界点判断标准很简单：状态数超过4个，或者状态间的事件处理存在大量“当前状态决定行为”的分支，这时候引入状态模式。如果你只有一个开关状态，老老实实写flag加if，别折腾。好的架构不是用最多模式，而是在正确的地方用正确的结构。

还有一点，无论选哪种方案，状态迁移表必须写在设计文档里。我真心觉得这比任何代码实现都重要。因为你不可能靠读代码把所有迁移关系都脑补出来，但是如果有一张表格，新同事半天就能上手状态机的全部逻辑，而你只需要在代码review时对照表格检查遗漏——这种收益是实打实的。

我做完这次重构后的实际感受是：状态模式真正解决的，不是“状态多了怎么办”，而是“状态多了之后，人怎么还能轻松把握全局”。它把分散在各处的状态判断收敛成一个一个可独立演进的类，加上一份清晰的迁移表，工程复杂度就回到了可控的范围。希望你接手的下一个状态机项目，也能在动手前先画好迁移矩阵，选好适合团队的实现风格，少踩几个我踩过的坑。