std::variant适用于多路互斥返回值场景，比union更安全，但不可存引用或重复类型；应配合std::visit强制处理所有分支，避免std::get硬取；与std::expected/std::optional分工明确，不适用于简单成败判断。
std::variant 适合替代多重返回值或 union 的场景
当函数可能返回几种互斥类型（比如成功时返回 int，失败时返回 std::string 或 std::error_code），std::variant 比裸指针、void* 或自定义 union 更安全——它自动管理析构、禁止二义性赋值，且支持访问时的类型检查。
典型误用是把它当“万能容器”塞任意类型，但 std::variant 要求所有备选类型可构造、可析构，且不能有重复类型（如 std::variant<int int></int> 编译不过）。
- 常见错误：把引用类型放进 variant（
std::variant<int double></int>）——不合法，variant 存储的是值语义 - 使用场景：网络请求结果（
std::variant<jsondata std::string std::exception_ptr></jsondata>）、解析器输出（std::variant<number string nullptr_t></number>） - 注意：如果其中某类型占用空间大（如
std::vector<char></char>），整个 variant 的 sizeof 会按最大成员对齐，可能浪费内存
用 std::visit 处理 variant 的每种可能分支
std::visit 是访问 std::variant 的唯一推荐方式，它强制你覆盖所有可能类型，避免漏处理。别用 std::get<t></t> 硬取——运行时抛 std::bad_variant_access 很难调试。
示例：假设 auto result = parse_input(); 返回 std::variant<int double std::string></int>：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
std::visit([](const auto& v) {
using T = std::decay_t<decltype>;
if constexpr (std::is_same_v<t int>) {
std::cout ) {
std::cout ) {
std::cout
<ul>
<li>必须用 <code>constexpr if</code>，普通 <code>if</code> 会导致未定义行为（编译期无法确定哪些分支可达）</li>
<li>lambda 参数用 <code>const auto&</code> 避免拷贝；若需修改，用非 const 引用，但确保 variant 本身非 const</li>
<li>如果 variant 含 <code>std::monostate</code>（空状态），必须显式处理，否则 <code>std::visit</code> 报错</li>
</ul>
<h3>std::holds_alternative 和 std::get_if 做运行时类型探测</h3>
<p>当你不确定 variant 当前持有什么类型，又不想写完整 visitor（比如只关心其中一种类型），用 <code>std::holds_alternative<t>(v)</t></code> 判断，再用 <code>std::get_if<t>(&v)</t></code> 安全取值。</p>
<p>比 <code>std::get<t>(v)</t></code> 更安全：后者失败直接 throw，而 <code>std::get_if</code> 返回 <code>T*</code>，空指针表示类型不匹配。</p>
<ul>
<li>常见坑：对 const variant 调用 <code>std::get_if<t>(&v)</t></code> 返回 <code>const T*</code>，解引用后不能修改</li>
<li>性能影响：<code>std::holds_alternative</code> 是 O(1) 查表，但频繁调用说明设计可能有问题——考虑是否该用 visitor 统一处理</li>
<li>注意：不要在循环里反复调用 <code>std::holds_alternative</code> 判断同一 variant，应提前缓存结果或改用 visit</li>
</ul>
<h3>和 std::optional、std::expected 的配合边界在哪</h3>
<p><code>std::variant</code> 不是万能错误处理方案。如果只有“成功/失败”两种状态，优先用 <code>std::expected<t e></t></code>（C++23）或 <code>std::optional<t></t></code> + 单一错误码；<code>std::variant</code> 更适合“多路分支结果”——比如解析 JSON 时可能得到数字、字符串、布尔、null、数组、对象六种类型。</p>
<ul>
<li>容易混淆点：把 <code>std::variant<t std::error_code></t></code> 当 <code>std::expected<t std::error_code></t></code> 用——后者有更清晰的语义和配套算法（如 <code>.and_then()</code>）</li>
<li>兼容性注意：<code>std::expected</code> 是 C++23 标准，旧项目只能靠第三方（如 <code>tl::expected</code>）或 variant 模拟</li>
<li>关键区别：<code>std::variant</code> 不自带“成功/失败”标签，你需要自己约定哪一个是 success 分支（比如第一个类型），否则调用方容易误解</li>
</ul>
<p>真正麻烦的不是怎么写 variant，而是决定哪些类型该放进同一个 variant——放太多，访问逻辑爆炸；放太少，又得嵌套多层 variant。这一步没想清楚，后面全是补丁。</p></t></decltype>C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
