应使用 std::variant 而非 enum class + switch 实现状态机,因其天然支持异构状态数据、编译期强制分支覆盖、避免 union 手动管理风险;需为各状态定义独立 struct、默认构造、operator==,并通过 std::visit 安全访问。

为什么不用 enum class + switch 写状态机
用 enum class 定义状态、靠 switch 分支跳转是最常见做法,但问题立刻浮现:每个状态要携带不同数据(比如“连接中”需要保存 socket fd,“认证失败”要存错误码,“空闲”则无需任何字段),硬塞进一个结构体就会导致大量未使用字段或 union 手动管理,易出错且不安全。std::variant 的价值就在这里——它天然支持「单个变量持有多种可能类型」,且编译期强制覆盖所有分支,避免漏处理。
- 状态类型必须互不相同,不能有重复(否则
std::variant编译失败) - 每个状态类建议定义
operator==,方便做状态相等判断(比如退出条件) - 不要直接在
std::variant里放裸指针或资源句柄;封装成 RAII 类型更稳妥
如何定义状态类型并组合成 variant
关键不是“怎么写 variant”,而是“怎么组织状态类”。推荐每个状态为独立 struct,带明确语义和所需字段:
struct Idle { };
struct Connecting { int sock_fd; std::string host; };
struct AuthFailed { int error_code; std::string message; };
struct Connected { int sock_fd; std::chrono::steady_clock::time_point last_active; };
<p>using State = std::variant<idle connecting authfailed connected>;</idle></p>
- 所有状态类型必须可默认构造(
std::variant初始化要求),哪怕只是空构造函数 - 如果某个状态需延迟初始化(比如
Connecting的sock_fd初始无效),用std::optional或约定 magic value(如 -1) - 避免在状态 struct 中放虚函数或继承体系——这会让
std::variant失去零成本抽象优势
怎么安全地触发状态迁移与访问当前状态数据
不能靠 get 强制取值,一旦类型不对就抛 std::bad_variant_access。正确姿势是用 std::visit + lambda:
State current_state = Idle{};
<p>// 迁移:直接赋新值
current_state = Connecting{123, "api.example.com"};</p><p>// 访问:只在匹配类型时执行逻辑
std::visit([](const auto& s) {
using T = std::decay_t<decltype>;
if constexpr (std::is_same_v<t connecting>) {
std::cout ) {
auto idle_time = std::chrono::steady_clock::now() - s.last_active;
std::cout </t></decltype></p>
-
if constexpr是必须的:普通if会导致所有分支代码都被实例化,编译失败(比如对Idle访问s.host) - 不要在 visit 外部用
std::holds_alternative+std::get查两次——性能差,且仍可能竞态(多线程下状态可能被改) - 若需频繁判断是否为某状态(如 while 循环守卫),封装成内联函数:
bool is_connected(const State& s) { return std::holds_alternative(s); }
状态机驱动逻辑怎么组织才不散乱
把状态迁移规则从主逻辑剥离,写成独立函数,输入旧状态 + 事件,输出新状态(或保持不变):
struct Event { enum Type { CONNECT, AUTH_SUCCESS, TIMEOUT, DISCONNECT }; Type type; };
<p>State transition(const State& s, const Event& e) {
return std::visit([&e](const auto& state) -> State {
using T = std::decay_t<decltype>;
if constexpr (std::is_same_v<t idle>) {
if (e.type == Event::CONNECT) return Connecting{0, ""};
return state;
} else if constexpr (std::is_same_v<t connecting>) {
if (e.type == Event::AUTH_SUCCESS) return Connected{state.sock_fd, std::chrono::steady_clock::now()};
if (e.type == Event::TIMEOUT) return AuthFailed{ETIMEDOUT, "connect timeout"};
return state;
} else if constexpr (std::is_same_v<t connected>) {
if (e.type == Event::DISCONNECT) return Idle{};
return state;
}
return state; // fallback, e.g. AuthFailed stays
}, s);
}</t></t></t></decltype></p>
- 迁移函数返回
State而非 void,便于单元测试和日志追踪(比如记录 “Idle → Connecting”) - 所有事件必须被显式处理,漏掉某个
if constexpr分支会导致编译失败(visit返回类型不匹配),这是std::variant带来的静态安全保障 - 实际项目中,事件往往带 payload(如认证失败的具体错误码),这时 event 类型本身也该用
std::variant或std::any,但要注意别让 event 变得比 state 还重
状态机真正的复杂点不在定义状态,而在于事件来源是否可靠、迁移是否可逆、以及异常路径(比如析构时状态处于中间态)如何兜底——这些没法靠 std::variant 自动解决,得靠设计约束。
C++免费学习笔记(深入):立即使用
在学习笔记中,你将探索 C++ 的入门与实战技巧!











