c++中如何优雅地处理函数返回值？ (std::optional和std::variant)_技术教程

std::optional适用于单个值可能缺失的场景，如查找或解析；std::variant适用于返回类型明确但互斥的多态场景，如JSON解析。二者解决不同抽象问题，不应随意嵌套或混用。

std::optional 适合表达“可能没有值”的函数返回

当函数逻辑上可能成功返回一个值，也可能因条件不满足而无法提供有效结果时，std::optional 比用特殊值（如 -1、nullptr）或额外输出参数更清晰。它把“有无值”变成类型系统的一部分，调用方必须显式处理空状态。

常见错误是忽略检查直接解包：value.value() 在 value.has_value() == false 时会抛 std::bad_optional_access。应该优先用 if (opt) { ... } 或 value.value_or(default_val)。

只用于单个可选值场景，比如查找容器中元素、解析字符串为数字
移动语义友好：返回 std::optional<:string> 不触发深拷贝
不能容纳 void 或引用类型；若需“可能无返回”，用 std::optional<:monostate>

std::optional find_first_even(const std::vector& v) {
    for (int x : v) {
        if (x % 2 == 0) return x;
    }
    return std::nullopt; // 显式表示无结果
}

// 调用侧
if (auto res = find_first_even({1, 3, 5})) {
    std::cout << "Found: " << *res << "\n";
} else {
    std::cout << "No even number\n";
}

std::variant 用于明确的多态返回类型

当函数可能返回几种**完全不同但已知**的类型（例如解析 JSON 字段时可能是 int、double、std::string），std::variant 是比 void* 或基类指针更安全的选择。它强制你在编译期枚举所有可能类型，并在运行时保证只持其中一种。

容易踩的坑是忘记处理所有分支：用 std::visit 时若 visitor 的 operator() 没覆盖 std::variant 中全部类型，会导致编译失败；但若用 std::get 强制取值，类型不匹配会抛 std::bad_variant_access。

类型列表必须互不兼容（不能有两个相同类型，也不能有 std::monostate 以外的空类型）
构造时推荐用 std::variant{A{...}} 而非 std::variant(A{...})，避免模板推导歧义
性能上，std::variant 通常用 union + 索引存储，访问是 O(1)，但比裸指针略重

using json_value = std::variant

json_value parse_json_field(const std::string& key) {
    if (key == "count") return 42;
    if (key == "price") return 19.99;
    if (key == "name") return std::string{"apple"};
    return std::monostate{}; // 表示 null 或未定义
}

// 安全访问
std::visit([](const auto& v) {
    using T = std::decay_t;
    if constexpr (std::is_same_v) {
        std::cout << "int: " << v << "\n";
    } else if constexpr (std::is_same_v) {
        std::cout << "string: " << v << "\n";
    } else if constexpr (std::is_same_v) {
        std::cout << "null\n";
    }
}, parse_json_field("count"));

别混用：optional 和 variant 解决的是不同抽象问题

std::optional 回答的是“有没有 T”，而 std::variant 回答的是“是 T、U 还是 V”。两者可以嵌套，但多数时候不该叠加使用——比如 std::optional<:variant>> 往往说明接口设计过载了：你其实想表达三种状态（A、B、none），那直接用 std::variant 更直白。

如果返回类型集合里只有一个“空”选项，优先选 std::optional
如果“空”只是多种合法状态之一（比如网络响应可能是 success、timeout、auth_error），就该用 std::variant
不要为了“统一返回类型”而强行把所有函数都改成 std::variant ——异常语义和控制流语义不该混在同一层

实际项目中要注意的隐性成本

这两个类型本身轻量，但它们带来的间接开销常被忽略：比如 std::optional<:string> 仍要管理堆内存；std::variant 的 std::visit 可能抑制内联，尤其当 visitor 是 lambda 且捕获较多变量时。调试时，GDB/LLDB 对 std::optional 和 std::variant 的显示支持也参差不齐，有时得手动打印 has_value() 或 index()。

最易被跳过的细节是移动语义一致性：若你返回 std::optional，确保 HeavyObject 自己正确实现了移动构造；否则 std::optional 的移动可能退化为拷贝。