std::variant 是实现携带异构数据的有限状态机唯一安全方案，因其能避免 std::bad_variant_access、字段误读、析构遗漏和运行时崩溃；std::get 危险因绕过编译期类型检查，应改用 std::get_if、std::holds_alternative 或 std::visit 配合显式枚举所有状态分支，并严格约束状态 struct 的构造与成员设计。
直接用 std::variant 实现有限状态机，不是“语法糖升级”，而是当状态携带异构数据（比如 Connecting 要存 socket 句柄和 IP 字符串，Connected 要带心跳时间点）时，唯一能避免 std::bad_variant_access、字段误读、析构遗漏和运行时崩溃的方案。
为什么 std::get<t>(state)</t> 是危险操作
它绕过编译器对状态分支的穷举检查，等于把类型安全交给运行时——只要当前 state 不是 T 类型，立刻抛 std::bad_variant_access。这种错误测试难覆盖，线上才暴露。
- 仅在已明确断言过类型的极少数场景可用（如状态转换入口做快速校验），绝不能出现在主逻辑分支中
- 真需要轻量判断某状态是否存在，改用
std::get_if<connecting>(&state)</connecting>，返回nullptr表示不匹配，需手动判空但安全 - 用
state.index()或std::holds_alternative<connecting>(state)</connecting>作主流程分支，同样放弃编译期保障，退化回传统enum+switch的漏处理风险
std::visit 必须显式覆盖所有状态类型
std::visit 的核心价值不是“方便分发”，而是让漏写某个状态分支成为编译错误。泛型 lambda 配合 if constexpr 看似简洁，但新手常因编译失败删掉分支、补个 else 了事，结果又回到运行时不可控。
- 推荐显式列出所有状态的写法：用
overloaded辅助模板（几行即可定义），例如std::visit(overloaded{ [](const Idle&) { /* ... */ }, [](const Connecting& s) { /* use s.sock */ } }, state) - 每个 lambda 参数必须为
const T&（非auto&&），否则if constexpr在部分特化下可能失效 - 新增状态时，编译器会报错指出哪个 lambda 缺失——这才是你该依赖的“强制审查机制”
状态 struct 设计的三个硬约束
每个状态 struct 不是容器，而是该状态的“数据契约”。违反任一约束，就会引入共享字段、默认构造无意义、或生命周期失控等隐患。
立即学习“C++免费学习笔记（深入）”；
- 禁止出现“可能为空”的成员：比如在
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 内部写 current_state = Connected{...} 看似可行，但副作用（如关闭旧 socket、记录日志、重置超时器）分散在各处，难以复用和测试。
- 为每个事件定义独立的 transition 函数，例如
State on_connect(const Idle&, const ConnectEvent& e)，返回新状态实例 - 主逻辑统一调用：
current_state = std::visit([&](const auto& s) -> State { return handle_event(s, ev); }, current_state) - transition 函数内可安全访问当前状态字段，并执行清理、日志、资源释放等副作用，保证原子性与可维护性
最易被忽略的是：状态 struct 的构造函数签名必须严格对应其数据契约，不能为了“灵活”接受通用配置对象；一旦某个状态开始塞 std::optional 或裸指针，整个零开销、类型安全、自动析构的优势就瓦解了。
