用std::variant实现有限状态机是唯一能避免std::bad_variant_access、字段误访问和生命周期失控的方案，因其强制每个状态仅含自身所需数据、编译期穷举分支、自动管理资源析构。
用 std::variant 实现有限状态机，不是“写得更现代”，而是当状态携带不同数据时，唯一能避免 std::bad_variant_access、字段误访问和生命周期失控的方案。
为什么不能直接用 enum class + 成员变量拼状态？
当你给每个状态都塞进同一个类里（比如 class FSM { enum State; int target_x; std::string error_msg; std::unique_ptr<socket> sock; }</socket>），就等于把所有状态的“可选字段”全摊在明面上。结果是：
- 绝大多数字段在多数状态下为空或未初始化，
target_x在Error状态下毫无意义，但你仍得检查它是否有效 -
error_msg只在出错时构造，却要全程占用内存，且析构时机完全依赖你手动控制 - 新增一个状态（如
Reconnecting）后，必须同步更新所有switch、所有字段判空逻辑、所有 assert，漏一处就是运行时崩溃
怎么定义状态类型才不踩坑？
每个状态必须是一个独立 struct，只放它真正需要的数据，且类型必须平凡可析构或自动管理资源。关键约束：
- 用
struct Idle {};表示无数据状态，别用std::monostate—— 后者语义模糊，后续加字段会破坏接口一致性 - 有 socket 或计时器的状态，直接存
int sock_fd;或std::chrono::steady_clock::time_point last_heartbeat;，std::variant会自动调用其析构函数 - 禁止出现跨状态复用字段名（如所有状态都叫
id），不同状态的id含义不同，就该用不同字段名（session_id/error_id） - 状态类型列表用
using State = std::variant<idle connecting connected error>;</idle>，顺序无关，但建议按常见流转顺序排列，方便阅读
为什么必须用 std::visit，而不能 std::get<Connecting>(state)？
std::get<T>(v) 是运行时断言：如果当前 v 不是 T 类型，直接抛 std::bad_variant_access。而 std::visit 是编译期强制穷举，漏写任一状态分支，编译即失败。
立即学习“C++免费学习笔记（深入）”；
推荐写法是显式列出所有分支（而非泛型 auto&& + if constexpr），因为后者容易漏掉某个 else if 分支后退化为 else，又回到运行时错误：
std::visit(overloaded{
[](const Idle&) { /* idle logic */ },
[](const Connecting& s) { /* use s.sock_fd */ },
[](const Connected& s) { /* use s.session_id, s.heartbeat_timer */ },
[](const Error& e) { /* use e.code, e.message */ }
}, state);注意：overloaded 是个辅助模板（可用 struct overloaded : Ts... { using Ts::operator()...; }; 实现），不是标准库组件，但必不可少。
状态变更时最容易忽略的原子性问题
状态变更不能拆成两步：先读旧状态做判断，再赋新值。例如：
// ❌ 危险：中间状态不一致
auto old = std::get_if<Connecting>(&state);
if (old && old->sock_fd == -1) {
state = Connected{session_id}; // 此刻 state 已变，但 old 指针可能失效
}正确做法是：用 std::visit 一次性完成“读+判+转”，或者用临时变量承接新状态再整体赋值：
// ✅ 安全：原子更新
auto next = std::visit([](const auto& s) -> std::optional<State> {
if constexpr (std::is_same_v<std::decay_t<decltype(s)>, Connecting>) {
if (s.sock_fd > 0) return Connected{s.session_id};
}
return std::nullopt;
}, state);
if (next) state = *next;真正的难点不在语法，而在设计初期就要想清楚：每个状态的边界是否干净、字段是否正交、转换逻辑是否能在一个 visit 闭包内闭环。一旦开始往 struct 里塞“通用配置对象”或“预留字段”，std::variant 的优势就立刻瓦解。
