应使用 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>;</p>- 所有状态类型必须可默认构造（
std::variant初始化要求），哪怕只是空构造函数 - 如果某个状态需延迟初始化（比如
Connecting的sock_fd初始无效），用std::optional<int></int>或约定 magic value（如 -1） - 避免在状态 struct 中放虚函数或继承体系——这会让
std::variant失去零成本抽象优势
怎么安全地触发状态迁移与访问当前状态数据
不能靠 get<t>(v)</t> 强制取值，一旦类型不对就抛 std::bad_variant_access。正确姿势是用 std::visit + lambda：
立即学习“C++免费学习笔记（深入）”；
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(s)>;
if constexpr (std::is_same_v<T, Connecting>) {
std::cout << "Connecting to " << s.host << "\n";
} else if constexpr (std::is_same_v<T, Connected>) {
auto idle_time = std::chrono::steady_clock::now() - s.last_active;
std::cout << "Idle for " << idle_time.count() << " ns\n";
}
}, current_state);</p>-
if constexpr是必须的：普通if会导致所有分支代码都被实例化，编译失败（比如对Idle访问s.host） - 不要在 visit 外部用
std::holds_alternative+std::get查两次——性能差，且仍可能竞态（多线程下状态可能被改） - 若需频繁判断是否为某状态（如 while 循环守卫），封装成内联函数：
bool is_connected(const State& s) { return std::holds_alternative<connected>(s); }</connected>
状态机驱动逻辑怎么组织才不散乱
把状态迁移规则从主逻辑剥离，写成独立函数，输入旧状态 + 事件，输出新状态（或保持不变）：
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(state)>;
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);
}</p>- 迁移函数返回
State而非 void，便于单元测试和日志追踪（比如记录 “Idle → Connecting”） - 所有事件必须被显式处理，漏掉某个
if constexpr分支会导致编译失败（visit返回类型不匹配），这是std::variant带来的静态安全保障 - 实际项目中，事件往往带 payload（如认证失败的具体错误码），这时 event 类型本身也该用
std::variant或std::any，但要注意别让 event 变得比 state 还重
状态机真正的复杂点不在定义状态，而在于事件来源是否可靠、迁移是否可逆、以及异常路径（比如析构时状态处于中间态）如何兜底——这些没法靠 std::variant 自动解决，得靠设计约束。
