std::get 访问类型不匹配时抛 std::bad_variant_access 异常，非未定义行为；std::get_if 是唯一安全的运行时提取方式，返回指针避免异常；多线程下 std::holds_alternative + std::get 有竞态风险，应改用 std::get_if 或 std::visit。
std::get 访问 std::variant 时类型不匹配直接崩溃
会触发 std::bad_variant_access 异常，不是未定义行为，但默认不捕获就是程序终止。c++ 标准明确要求：当 std::get<t>(v)</t> 中 T 不是当前持有的类型时，必须抛出该异常。
- 不是静默返回垃圾值，也不是 segfault（除非你用
std::get_if返回空指针后解引用） - 在
release模式下仍会抛异常——这不是调试断言，是强制语义 - 如果没写
try/catch，且异常未被上层捕获，进程就 exit(1)，日志里通常只有一行terminate called after throwing an instance of 'std::bad_variant_access'
std::get_if 是唯一安全的运行时类型提取方式
std::get_if 返回的是 T*（不是 T&），空指针表示类型不匹配，完全规避异常路径。它才是面向生产环境的访问姿势。
- 适用于需要分支处理不同类型、或允许“无此类型”的场景（比如解析配置项）
-
std::get_if<int>(&v)</int>和std::get_if<:string>(&v)</:string>参数必须是指向std::variant的指针，传值或引用会编译失败 - 性能几乎无开销：内部只是比较当前 index 和目标类型的序号，比
std::holds_alternative多一次指针解引用，但远快于异常抛出路径
std::holds_alternative(v) 应该和 std::get_if 配合使用，而不是替代
单独用 std::holds_alternative 判断后再调 std::get，看似安全，实则引入竞态窗口——variant 可能被其他线程修改（即使你没显式并发，某些封装库或回调可能隐式触发）。
- 多线程下，两次访问（先判再取）之间 variant 状态可能已变，
std::get仍会抛异常 - 单线程下虽不会出错，但多一次比较 + 多一次访问，纯属冗余；不如直接用
std::get_if一步到位 - 若需 match 多种类型，优先用
std::visit，它天然原子、类型安全、无重复判断
std::visit 的 Lambda 捕获容易忽略 const 与引用语义
在 lambda 里对 variant 成员做非 const 修改，或者意外拷贝大对象，是常见性能与逻辑陷阱。
立即学习“C++免费学习笔记（深入）”；
- 写
[](auto&& x) { x = ...; }时，x是右值引用，修改的是临时副本，原 variant 不变 - 想原地修改，得用
[](auto& x) { x = ...; }，但要确保所有分支类型都支持赋值（比如const int就不行） - 避免在 lambda 参数里写具体类型（如
(int x)），否则其他类型分支无法编译；用auto或重载operator()类更好
实际写业务逻辑时，最常被跳过的其实是「variant 是否为空」这个前提——std::monostate 是合法的首项类型，但很多人忘了检查它，导致 std::get_if<t></t> 返回空指针后继续用，结果段错误。这跟类型检查无关，是状态建模遗漏。