std::variant 仅在状态携带互不兼容、结构差异大的数据时才值得使用；否则会带来编译慢、错误隐蔽、内存浪费等问题。
std::variant 不是用来给所有状态机“升级”的，它只在状态携带互不兼容、结构差异大的数据时才真正值得用；否则你只是用编译慢、错误隐蔽、内存浪费换来了心理安慰。
什么时候该用 std::variant 而不是 enum class
核心就看字段是否“按状态分裂”：如果 ConnectingState 需要 std::string address 和 int retry_count，ConnectedState 需要 int sockfd 和 std::chrono::seconds timeout，而 IdleState 真的什么也不需要（定义为 struct Idle {};），那共享字段少于 50%，std::variant 就是更干净的选择。
硬套 enum class State { Idle, Connecting, Connected } + 一个大 struct 塞满 std::optional 字段，会导致：
- 每次访问前必须反复判
has_value()，漏一次就是未定义行为 - 构造时容易漏初始化某字段，尤其新增状态后
- 内存始终按最大状态对齐，Idle 状态也占着
std::string的空间
std::visit 必须用 if constexpr + std::decay_t
写 std::visit([](auto& s) { ... }, state) 是常见起点，但直接在里面用普通 if 或 typeid 会绕过编译期检查，等于白用 std::variant。
立即学习“C++免费学习笔记（深入）”；
正确写法必须同时满足三点：
- 参数用
const auto& s，避免对含std::string或std::vector的状态意外触发移动 - 第一行写
using T = std::decay_t<decltype>;</decltype>，否则std::is_same_v<T, ConnectingState>永远为 false - 每个分支必须用
if constexpr，否则编译器会对所有分支尝试实例化——哪怕当前是ConnectedState，也会因访问ConnectingState::address报错
漏掉任一状态类型（比如加了 ReconnectingState 却没加对应 if constexpr 分支），编译直接失败。这不是 bug，是保护机制。
状态变更必须原子赋值新对象
状态跳转不是“改几个字段”，而是整个状态值的替换。禁止对 std::get<ConnectingState>(state) 返回的引用做字段级更新，这绕过了 std::variant 的类型安全和生命周期管理。
正确做法是：
- 把新状态所需全部参数收齐（比如从
ConnectingState进入ConnectedState时，显式传入 socket fd） - 构造完整新对象：
state = ConnectedState{fd, timeout};或state = std::in_place_type<ConnectedState>, fd, timeout; - 禁止先设
state.index()再填字段，或用裸指针/全局变量“共享”数据——中间状态不一致的风险极高，尤其在异常路径下
别在 variant 中存大对象或裸指针
std::variant 对象本身在栈上，里面存的每个类型都得能放进栈空间。如果某个状态需要缓冲区或大量数据，比如 std::vector<uint8_t>，直接塞进去会导致栈暴涨、移动开销不可控。
实操建议：
- 优先用
std::unique_ptr<T>包一层，把大对象挪到堆上，保持栈轻量 - 绝对不要存裸指针（如
int*或char*），这等于把内存管理责任推给上层，违背std::variant自动析构的设计初衷 - 空状态别用
std::monostate凑数，除非你真需要“无状态”作为合法初值；语义模糊的std::monostate容易掩盖逻辑缺陷，后续加字段也难扩展
最常被忽略的点是：状态结构体的构造函数必须只接收其必需参数，且每个字段都应是该状态“必要且充分”的数据——没有预留字段，不跨状态复用字段名，不靠注释约定“这个字段只在 X 状态有效”。一旦开始妥协，std::variant 的类型安全优势就瓦解了。
