用 std::variant 实现状态机是唯一靠谱方案，因每个状态为独立 struct，字段不共享、生命周期自动管理，且必须用 std::visit 穷举访问，确保类型安全与状态完整性。
直接用 std::variant 实现有限状态机，是当状态携带不同数据时唯一靠谱的选择——不是更“现代”，而是不这么写，迟早掉进 reinterpret_cast、裸 union、满屏 if (state == X) { /* 访问可能为空的字段 */ } 的坑里。
为什么 enum class + 成员变量拼凑的状态类行不通
当你发现类里开始堆砌大量“只在某个状态下有效”的字段（比如 target_x 只属于 MovingState，error_code 只属于 ErrorState），就说明枚举+共享成员的设计已崩溃。
常见错误现象：
- 为兼容所有状态，把所有字段塞进一个类，靠
assert(state == Moving)防护访问 —— 运行时才崩，编译器不管 - 手动管理字段生命周期：构造时只初始化部分成员，析构时不敢乱调 dtor，容易内存泄漏或 double-free
- 新增状态要全局搜索所有
switch，漏改一处就是静默逻辑错误
根本问题在于：状态语义被弱化成一个整数标签，而真正承载行为和数据的是“类型”本身。枚举无法表达“这个状态必须带 socket 句柄”这种约束。
如何正确定义状态 variant 类型
核心原则：每个状态是一个独立 struct，只放它真正需要的字段，不预留、不共享、不妥协。
实操建议：
- 用
using State = std::variant统一封装，所有状态 struct 定义在头文件中; -
IdleState真没数据就定义为空struct IdleState {};；别用std::monostate占位——后者语义模糊，后续加字段困难 - 禁止在
variant中存指针（如std::variant）；资源（int socket_fd、std::unique_ptr）直接放进 struct，让variant自动管理其构造/析构 - 每个状态 struct 的构造函数只接收必需参数，例如
ConnectingState(int fd, std::string ip)，拒绝“通用配置对象”传参
必须用 std::visit 访问状态，禁用 std::get
std::get 是危险操作：运行时若当前不是该类型，抛 std::bad_variant_access，且绕过编译期检查。
正确做法是用 std::visit 强制穷举所有分支：
std::visit(overloaded{
[](const IdleState&) { /* 处理空闲逻辑 */ },
[](const ConnectingState& s) { std::cout <p>容易踩的坑：</p>
- 漏写任一状态分支 → 编译失败（这是好事），但新手常改成
else分支兜底，退化回运行时错误 - lambda 参数写成
auto&&而非具体类型 →if constexpr分支里无法获得准确类型信息，编译报错难定位 - 在
visit回调里直接修改state（如state = ConnectedState{...}）→ 状态变更应原子完成，推荐先计算新值再整体赋值
状态变更必须原子更新整个 variant
不要在旧状态里“打补丁”式修改字段（如 state.get），这会制造中间不一致状态。
实操建议：
- 所有状态转换逻辑封装在独立函数中，返回新的
State值，例如：State onConnectSuccess(int fd, std::string ip) { return ConnectedState{fd, ip, std::chrono::steady_clock::now()}; } - 外部统一用
state = onConnectSuccess(fd, ip);替换整个 variant，保证状态始终完整、自洽 - 若需跨状态共享字段（如日志 ID、时间戳），应提取到 FSM 容器类中，而非塞进每个状态 struct —— 共享超过 50% 字段才考虑基类，否则就是设计污染
最易被忽略的一点：状态 struct 的字段命名必须具备强语义，避免 data、value 这类泛化名。因为一旦名字模糊，就很难判断它是否真的只属于该状态——而这正是 variant 状态机安全性的根基。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
