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 时才报错,不是定义时。
- lambda 参数类型必须匹配 variant 中每个备选类型,否则编译不过
- 若 variant 含
std::monostate,lambda 必须接受它,哪怕只写个空实现 - 想提前退出?不能用
return跳出 visit,只能靠异常或封装成函数对象返回值 - 示例:
std::visit([](const auto& x) -> std::string { if constexpr (std::is_same_v<decltype const int>) return "int: " + std::to_string(x); else if constexpr (std::is_same_v<decltype const std::string>) return "str: " + x; else return "unknown"; }, v);</decltype></decltype>
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: 分支,否则编译通不过。C++免费学习笔记(深入):立即使用
在学习笔记中,你将探索 C++ 的入门与实战技巧!











