std::visit 不是“万能胶”：手把手拆解 variant 当前值的访问逻辑

你写好了 std::variant<int, std::string, double>，也用 std::get_if 检查过类型，但一到真正想对当前值做点事——比如格式化输出、参与计算、转成 JSON 字段——就卡住了。std::visit 看似简单，可一旦传个 lambda 里套个 if constexpr，或者试图在访客里改 variant 本身，编译器立刻甩你一串红字。这不是你代码写得差，而是 std::visit 的行为边界，很多人根本没摸清。

std::visit 的核心任务只有一个：安全地、静态分发地调用一个可调用对象，参数是 variant 当前持有的那个确切类型的值（按 const/volatile/引用限定符原样传递）。它不负责类型判断，不负责异常兜底，更不负责帮你“猜”你想干什么。它只做一件事：把钥匙（当前值）交到你手上，门（类型分支）已经由编译器提前焊死了。

先看最常踩的坑：以为 std::visit 能“自动适配”任意函数。
比如有人这么写：

std::variant<int, std::string> v = "hello";
std::visit([](auto&& x) { std::cout << x << '\n'; }, v); // ✅ 正确

这能过，是因为 lambda 是泛型的，每个实例化版本都恰好匹配一种类型。但换成：

void print_int(int x) { std::cout << "int: " << x; }
void print_str(const std::string& s) { std::cout << "str: " << s; }
std::visit(print_int, v); // ❌ 编译失败：print_int 不接受 string

std::visit 不会帮你重载解析，它只认一个可调用体。必须确保这个可调用体对 variant 所有备选类型都提供合法重载。最稳妥的做法，是用 std::overload 辅助构造一个支持多类型的访客：

template<class... Ts> struct overload : Ts... { using Ts::operator()...; };
template<class... Ts> overload(Ts...) -> overload<Ts...>;

std::variant<int, std::string, double> v = 3.14;
std::visit(overload{
    [](int i) { std::cout << "got int: " << i; },
    [](const std::string& s) { std::cout << "got string: " << s; },
    [](double d) { std::cout << "got double: " << d; }
}, v);

这里的关键不是语法炫技，而是显式声明你已穷尽所有可能路径。编译器看到 overload{...} 里覆盖了 variant 的全部类型，才敢放行。漏掉一个？直接编译失败——这是 variant 给你的安全护栏，别嫌它烦。

另一个真实困扰：想在访客里修改 variant 本身。比如根据当前值决定塞进新值：

std::variant<int, std::string> v = 42;
std::visit([](auto&& x) {
    if constexpr (std::is_same_v<std::decay_t<decltype(x)>, int>) {
        x = x * 2; // ❌ 错！x 是 const int& 或 int&&，不能赋值
    }
}, v);

问题出在 std::visit 默认以 const T& 或 T&& 形式传递值（取决于 variant 本身的 cv 限定和值类别）。它传递的是“视图”，不是“句柄”。要修改 variant 内容，得把 variant 本身捕获进去，并用 std::get 或 std::get_if 显式更新：

std::visit([&v](auto&& x) {
    using T = std::decay_t<decltype(x)>;
    if constexpr (std::is_same_v<T, int>) {
        v = x * 2; // ✅ 直接赋值给 variant
    } else if constexpr (std::is_same_v<T, std::string>) {
        v = x + "!";
    }
}, v);

注意：这里 v 是按引用捕获的，且赋值操作触发 variant 的类型替换（如果新类型不同），std::visit 本身不参与这个过程。

还有一种场景：variant 嵌套了其他 variant，或者你想递归处理。std::visit 不递归，它只处理一层。此时需要手动展开：

using Inner = std::variant<int, char>;
using Outer = std::variant<Inner, std::string>;

Outer o = Inner{42};
std::visit([](auto&& x) {
    if constexpr (std::is_same_v<std::decay_t<decltype(x)>, Inner>) {
        std::visit([](auto&& inner_val) {
            std::cout << "inner: " << inner_val;
        }, x); // ✅ 对 inner variant 再次 visit
    } else {
        std::cout << "outer string: " << x;
    }
}, o);

最后一句实在话：std::visit 不是银弹。当 variant 类型超过 5 种，或分支逻辑高度相似（比如全都要序列化），硬写 overload 会变得臃肿。这时不妨退一步：用 std::visit 提取当前值，再交给一个统一的处理函数。例如：

struct Serializer {
    template<typename T>
    static std::string to_json(const T& val) {
        if constexpr (std::is_same_v<T, int>) return std::to_string(val);
        else if constexpr (std::is_same_v<T, std::string>) return "\"" + val + "\"";
        else if constexpr (std::is_floating_point_v<T>) return std::to_string(val);
    }
};

std::string json = std::visit([](const auto& x) {
    return Serializer::to_json(x);
}, v);

这样既保持 visit 的简洁性，又把复杂逻辑收口到模板特化里，维护成本更低。

std::visit 的价值，从来不在“能做什么”，而在于“强制你面对所有可能性”。它逼你写出确定性的分支，而不是靠运行时 if 猜类型。写多了你会明白：那点编译时的啰嗦，换来的是一次性消灭 bad_variant_access 异常的踏实感——就像每次出门前确认钥匙带没带，麻烦，但比半夜蹲在锁着的门口强。