C++ std::variant在有限状态机编程中的应用实战方案现代技巧

用 std::variant 写状态机是唯一能避免运行时崩溃的方案：std::get 危险因抛 bad_variant_access，须用 std::visit 显式覆盖所有状态；状态 struct 必须无 optional/裸指针/非 noexcept 析构；状态更新需原子赋值。

c++ std::variant在有限状态机编程中的应用实战方案现代技巧 _ 技巧【实战】

用 std::variant 写状态机，不是“换种写法”，而是当状态携带不同数据时，唯一能避免 std::bad_variant_access、字段误访问、析构遗漏和运行时崩溃的方案。

为什么 std::get(state) 是危险操作

直接用 std::get<connecting>(state)</connecting> 强制取值，等于把类型安全交给运气：一旦 state 当前实际是 Idle 或 Error，程序立刻抛 std::bad_variant_access —— 这是运行时错误，测试难覆盖，线上才暴露。

它绕过编译器对分支完整性的检查，退化回传统 enum + switch 的漏处理风险
std::get 适合临时调试或已明确断言过类型的极少数场景（如状态转换入口），绝不该出现在主逻辑分支中
若真需要按类型取指针做轻量判断，改用 std::get_if<connecting>(&state)</connecting>，返回 nullptr 表示不匹配，安全但需手动判空

std::visit 必须显式覆盖所有状态类型

std::visit 的核心价值不是“方便分发”，而是让漏写某个状态分支成为编译错误。泛型 lambda（[](const auto& s) { ... }）配合 if constexpr 看似简洁，但新手常因编译失败删掉分支、补个 else 了事，结果又回到运行时不可控。

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

推荐写法是显式列出所有状态：用 overloaded{ [](const Idle&) { ... }, [](const Connecting& s) { use(s.sock); }, ... }（overloaded 是常见辅助模板，几行即可定义）
每个 lambda 参数必须为 const T&（非 auto&&），否则 if constexpr 在部分特化下可能失效
新增状态时，编译器会报错指出哪个 lambda 缺失 —— 这才是你该依赖的“强制审查机制”

状态 struct 设计的三个硬约束

每个状态 struct 不是容器，而是该状态的“数据契约”。违反以下任一约束，就会引入共享字段、默认构造无意义、或生命周期失控等隐患。

禁止出现“可能为空”的成员：比如在 Connecting 里塞 std::optional<socket_t></socket_t>，而它本该由构造函数强制传入 —— Connecting(socket_t s, std::string ip) 才是正确签名
空状态（如 Idle）必须定义为 struct Idle {};，而非 std::monostate：std::monostate 语义模糊，后续加字段（如 Idle{bool was_recently_active}）会破坏二进制兼容性
禁止放入裸指针（std::variant<a b></a>）：这等于放弃 std::variant 自动析构的优势，资源管理责任被踢给上层，极易泄漏

状态更新必须原子且不可拆分

状态变更不能靠“先改字段再改枚举”，也不能在 std::visit 里边读边写。正确做法是：一次构造新状态，一次赋值替换整个 std::variant。

例如从 Connecting 转到 Connected，不要写 state = Connected{session_id, timer}; —— 这没问题；但绝不要写 std::get<connecting>(state).sock = new_sock;</connecting>，因为此时 state 可能根本不是 Connecting
若转换逻辑复杂（如需根据当前状态计算新状态），把整个逻辑封装进一个纯函数：State next_state(const State& current, const Event& e) { return std::visit(...); }，然后 state = next_state(state, e);
注意：std::variant 赋值会触发旧状态析构、新状态构造，确保中间态不会残留未析构对象 —— 这是它比裸 union 和手动 enum 安全的根本原因

最易被忽略的一点：状态 struct 的析构函数必须是 noexcept（或默认隐式满足）。如果某个状态持有 std::vector 或 std::string，它们的析构天然 noexcept；但若你手动写了可能抛异常的析构函数，std::variant 的赋值/移动操作会编译失败 —— 这不是 bug，是设计强制你面对资源清理的确定性。