std::visit编译报错主因是visitor未覆盖variant所有类型，泛型lambda或std::overload可解决；修改值需传非const引用；现代编译器优化后性能接近手工switch，核心优势是类型安全与自动资源管理。
std::visit 调用时编译报错：no matching function for call
常见于访问 std::variant 时传入了不匹配的 visitor 类型，比如 lambda 捕获了局部变量但没声明为 mutable，或 visitor 没覆盖所有可能类型。
关键点是：visitor 必须对 std::variant 中**每一个备选类型**都提供可调用的重载（或能 fallback 的泛化操作）。否则编译器无法做 SFINAE 推导，直接报错。
- 用
std::visit([](const auto& v) { /* ... */ }, var)这种泛型 lambda 最省事，自动适配所有类型 - 若需区分处理，优先用
std::overload辅助类组合多个 lambda，别手写 functor 类——容易漏掉某个类型 - 注意 const/volatile 限定符一致性：如果 variant 存的是
int，但 lambda 参数写成int&，而实际值是右值，就会失败
想在 visit 里修改 variant 当前持有的值，怎么写
std::visit 本身不修改 variant，但它可以触发修改逻辑。关键是让 visitor 返回新值，并用 std::get_if 或 std::holds_alternative 配合 std::variant::operator= 来更新。
更直接的做法：把 variant 以非 const 引用传入 visitor，在 lambda 内部直接赋值。但要注意——必须确保你修改的是原对象，而不是副本。
立即学习“C++免费学习笔记（深入）”；
- 传参用
std::variant<t...>&</t...>，不是const std::variant<t...>&</t...> - lambda 参数也得是非 const 引用，例如
[](auto& v) { v = 42; }，否则v = ...只作用于临时拷贝 - 如果只是想“替换为另一类型”，直接
var = NewType{...}即可，std::visit不是必需的
std::visit 性能开销大不大？能不能避免运行时分支
现代编译器（GCC 10+、Clang 12+）在 visitor 是泛型 lambda 且 variant 类型数不多时，常能把 std::visit 优化成无分支的跳转表或内联展开，实测和手工 switch 差距极小。
但以下情况会抑制优化：
- visitor 是函数指针或虚函数对象（失去编译期信息）
- variant 含大量类型（> 8），某些 STL 实现退化为链式 if-else
- 用了
std::visit嵌套，且外层 visitor 捕获了复杂状态
如果真卡在性能关键路径，且类型集合固定，可以用 std::variant 的 index() + switch 手动 dispatch，但要自己维护类型顺序一致性——稍不注意就和 variant 定义脱节。
和 C++17 之前的手写 union + tag 方案比，优势在哪
核心是类型安全：编译器强制你处理所有分支，不会漏 case；自动管理构造/析构，不用手动调 placement new 和显式 destructor 调用；支持移动语义和异常安全。
代价是轻微内存开销（额外 1 字节存 index）和部分场景下略高的抽象层级。但绝大多数业务代码里，这点成本远低于人工维护 union 出错的概率。
- 老方案中
memcpy错位、未调析构函数、tag 和数据不同步——这些 bug 很难静态发现 -
std::variant的std::get_if和std::holds_alternative是零成本抽象，编译后就是查 index - 别为了“看起来更底层”而放弃
std::visit，除非 profiler 明确指出它是瓶颈
类型切换这事，真正麻烦的从来不是语法怎么写，而是确保每次新增一种类型时，所有 visit 调用点都同步更新——这个靠人盯不如靠编译器报错。
