std::visit是std::variant唯一类型安全的访问方式，漏处理任一类型将编译失败；std::get和std::get_if放弃编译期检查，易引发未定义行为且无法保障穷举性。
直接说结论：std::visit 是 std::variant 唯一推荐的、类型安全的访问方式；它不是“可选的访问手段”，而是强制性的设计契约——漏掉任一类型分支，编译失败；用 std::get 或 std::get_if 做运行时分发，等于主动放弃类型安全和维护性。
std::visit 编译报错 “no matching function for call” 怎么快速定位
这几乎总是重载不全或 cv 限定不匹配造成的。编译器不会告诉你缺哪个类型，只会说“找不到可行重载”。常见诱因：
- 漏写某个
std::variant成员类型的operator()，比如std::variant中没处理double - 参数用了
const T&，但 variant 当前持有时是右值（如临时std::string），而你没提供T&&重载 - lambda 写成
[](int x) { ... }，而非[](auto&& x) { ... }或显式结构体，导致只覆盖一种类型 - 访问者类里用了模板
template，它会“吃掉所有类型”，掩盖漏处理问题void operator()(const T&)
为什么不能用 std::get(v) 实现类型分发逻辑
std::get 是断言式访问：它假设你 100% 确定 v 此刻持有 T。一旦错判，抛出 std::bad_variant_access ——这不是可捕获的异常，而是未定义行为的临界点。更危险的是，它无法穷举检查：
- 你写
if (std::holds_alternative，看似安全，但若后续往(v)) { std::get (v); } std::variant类型列表加了long，这段代码仍能编译通过，却完全忽略新类型 -
std::get_if返回指针，空指针需手动判空，逻辑分散且易遗漏(&v) - 所有基于
std::holds_alternative的 if-else 链，本质是运行时线性查找，性能差，且无编译期保障
怎么写一个真正安全、可扩展的 visitor 结构体
别依赖泛型 lambda 做“统一处理”，尤其当各类型逻辑差异大时。正确姿势是显式定义 visitor 类，并让每个 operator() 精准匹配一种类型：
- 参数用
const T&（避免拷贝）或T&&（支持移动语义），不要裸T - 每个重载函数名必须是
operator()，且签名与std::variant中对应类型完全一致（含 const、引用、cv 限定） - 如果需要状态（如递归深度计数器），用成员变量，而非 lambda 捕获——后者在递归调用或跨线程场景下不可靠
- 继承不必要，但可加
static_assert校验是否覆盖全部类型（C++20 起可用requires表达式）
例如：
std::variant
- 节点 struct 必须可默认构造，否则
std::variant初始化失败；字段尽量用std::string、int、std::vector等值类型，禁用std::unique_ptr或裸指针 - 递归嵌套时（如
BinaryOp::lhs是另一个Expr），必须用using Expr = std::variant<...>;提前声明，否则定义顺序导致编译错误 -
std::visit本身开销极小，但 visitor 里做深拷贝、字符串拼接、IO 等耗时操作，会直接拖慢解析热点路径——把副作用移出 visitor，只留纯计算和分发
复杂点从来不在语法，而在你是否真让编译器替你检查了所有分支。漏一个 operator()，就等于给未来埋了一个 runtime crash 的定时器。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
