std::variant适合替代union或多重返回值，用于互斥类型场景，比裸union安全、比std::pair清晰，但需用std::holds_alternative或std::visit安全访问，避免std::bad_variant_access；含std::monostate需显式声明；优先用std::expected处理“成功/失败”，variant适用于多合法结果的模式匹配。
std::variant 适合替代 union 或多重返回值场景
当函数可能返回几种互斥类型（比如成功时返回 int，失败时返回 std::string 错误信息），std::variant 比裸 union 安全，也比用 std::pair<bool t></bool> 更清晰。它强制你显式处理每种可能，避免未定义行为。
常见错误是直接访问某个类型而不检查——比如调用 std::get<int>(v)</int> 但 v 实际存的是 std::string，会抛出 std::bad_variant_access。
- 必须用
std::holds_alternative<t>(v)</t>先判断，或用std::visit统一分发 - 不能把
std::monostate忘在类型列表里——如果需要“空状态”，得显式写进去，比如std::variant<:monostate int std::string></:monostate> - 构造时注意隐式转换：如果类型间有构造函数冲突（比如两个类都能从
int构造），编译器可能无法推导，需显式构造std::variant<int double>{42}</int>
用 std::visit 处理 variant 的所有分支
std::visit 是安全访问 std::variant 的推荐方式，它强制覆盖所有类型，编译期检查是否遗漏分支。Lambda 写法最常用，但要注意捕获方式和返回类型一致性。
典型错误是 lambda 返回类型不一致（比如一个分支返回 int，另一个返回 void），导致编译失败；或者忘记处理某一种类型，而编译器只在调用 std::visit 时才报错，不是定义时。
立即学习“C++免费学习笔记（深入）”；
- lambda 参数类型必须匹配 variant 中每个备选类型，否则编译不过
- 若 variant 含
std::monostate，lambda 必须接受它，哪怕只写个空实现 - 想提前退出？不能用
return跳出 visit，只能靠异常或封装成函数对象返回值 - 示例：
std::visit([](const auto& x) -> std::string { if constexpr (std::is_same_v<decltype(x), const int&>) return "int: " + std::to_string(x); else if constexpr (std::is_same_v<decltype(x), const std::string&>) return "str: " + x; else return "unknown"; }, v);
std::get 和 std::get_if 的适用边界
std::get<t>(v)</t> 直接取值，适用于你**确定当前 variant 存的是 T 类型**的场景，比如刚用 std::holds_alternative<t>(v)</t> 检查过。而 std::get_if<t>(&v)</t> 返回指针，更安全——取不到就返回 nullptr，不抛异常。
容易踩的坑是混淆两者语义：std::get 像“我相信你是这个”，std::get_if 像“我试试看是不是这个”。生产代码里优先用 std::get_if，除非性能敏感且逻辑已确保类型正确。
-
std::get_if对 const variant 返回const T*，别试图解引用后赋值 - 对含
std::monostate的 variant，std::get_if<:monostate>(&v)</:monostate>可用于检测是否为空 - 不要对
std::variant成员变量反复调用std::holds_alternative+std::get，效率低且易漏分支——改用std::visit
和 std::optional、std::expected 的分工区别
std::variant 不是万能错误处理方案。它适合“多种合法结果”的建模（如解析 JSON 得到 string/number/array），而不是“成功 or 失败”这种二元语义。后者用 std::expected（C++23）或 std::optional + 错误码更自然。
滥用 std::variant 会导致类型列表膨胀、访问逻辑复杂。比如 std::variant<int std::string std::runtime_error></int> 看似覆盖了所有情况，但把错误当作普通值混入业务类型，破坏了关注点分离。
- 如果只有两种状态且其中一种是“无效”，优先考虑
std::optional<t></t> - 如果需要携带错误上下文（如错误码+消息），
std::expected<t e></t>更合适，它支持链式操作（.and_then()） -
std::variant的真正优势在于模式匹配式 dispatch，比如解析器根据 token 类型分发不同处理逻辑
std::monostate 的必要性——很多人以为 variant 默认可为空，其实不然；还有就是 std::visit 的 lambda 必须穷尽所有类型，哪怕只是加个 default: 分支，否则编译通不过。 
