std::visit强制编译期全覆盖所有variant类型分支，漏写或签名错误直接编译失败；修改值需v为非const引用且lambda参数为非const引用；泛型lambda配合if constexpr实现安全类型特化。
std::visit 不是“调用一次就完事”的工具，它强制你面对所有类型分支——漏一个，编译直接失败；写错签名，连模板推导都过不了。真正安全、可维护的分发逻辑，得从 visitor 的构造方式开始设计。
visitor 必须覆盖所有类型，否则编译失败
这是最常被忽略的硬性约束：std::visit 要求传入的 visitor 对 std::variant 的每一个备选类型都必须可调用。不是“运行时跳过”，而是“编译期拒绝”。
常见错误现象：
-
std::variant<int std::string double> v = "test"; std::visit([](int) {}, v);</int>→ 报no matching function for call to 'visit' - 手写 functor 只实现了
operator()(int)和operator()(const std::string&)，但忘了double→ 同样编译失败
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 优先用泛型 lambda：
[](auto&& x) { /* 通用处理 */ }，它会为每个类型实例化一次，天然全覆盖 - 需要差异化逻辑时，用
std::overload组合多个 lambda：std::visit(std::overload{ [](int i) {}, [](const std::string& s) {}, [](double d) {} }, v) - 别手写 functor 类——除非你愿意每次增删类型都去同步改一堆
operator()，且保证 noexcept / const 正确性
修改 variant 值必须用非 const 引用
std::visit 本身不修改 std::variant，但它能成为修改的入口。关键在“传进去的是什么”和“lambda 接收的是什么”。
错误写法（毫无效果）：
std::visit([](auto x) { x = 42; }, v); // x 是值拷贝正确写法（两处引用缺一不可）：
- 把
v以非 const 引用传入：std::visit(visitor, v)（不是const std::variant<...>&</...>） - lambda 参数也必须是非 const 引用：
[](auto& x) { x = 42; }或[](int& i) { i = 42; } - 若只是想替换整个 variant 的类型（比如从
int换成std::string），直接写v = std::string{"new"}更清晰，不必绕路std::visit
泛型 lambda 里做类型特化：constexpr if 是关键
泛型 lambda 看似“一招鲜”，但实际业务中往往需要对不同类型执行完全不同的逻辑（比如 int 做数值计算，std::string 做格式化，double 做精度判断）。这时不能只靠 typeid 运行时判断——那失去了 std::variant 编译期类型安全的意义。
正确做法是结合 if constexpr + std::decay_t：
std::visit([](auto&& arg) {
using T = std::decay_t<decltype(arg)>;
if constexpr (std::is_same_v<T, int>) {
std::cout << "int: " << arg * 2;
} else if constexpr (std::is_same_v<T, std::string>) {
std::cout << "string len: " << arg.length();
} else if constexpr (std::is_same_v<T, double>) {
std::cout << "double (2 decimals): " << std::fixed << std::setprecision(2) << arg;
}
}, v);注意点：
-
if constexpr在编译期裁剪分支，未匹配的代码不会参与编译，避免了类型不合法操作（比如对int调用.length()） - 必须用
std::decay_t去除引用和 const，否则std::is_same_v<T, std::string>会因const std::string&而失败 - 不要用
std::is_integral_v<T>这类宽泛 trait 替代具体类型判断——std::variant<int, long>中两者都满足，但语义可能完全不同
最易被忽略的其实是“类型列表变更时的连锁反应”：加一个新类型，不只是改声明，所有 std::visit 调用点都得检查是否覆盖、是否需更新 constexpr if 分支、是否影响非 const 引用修改逻辑。这不是语法细节，而是接口契约的一部分。
