std::get_if 为什么比 std::get 更安全？
因为 std::get 在类型不匹配时直接抛 std::bad_variant_access 异常，而 std::get_if 返回指针——匹配则返回非空指针，不匹配则返回 nullptr，完全绕过异常路径。这对性能敏感或禁止异常的场景（如嵌入式、游戏逻辑主循环）是刚需。
常见错误现象：std::get<int>(v)</int> 在 v 实际存的是 double 时崩溃（未捕获异常），而 std::get_if<int>(&v)</int> 只是返回 nullptr，可控。
- 必须传入左值引用（
&v），不能传右值或临时对象 - 返回的是指向内部值的指针，生命周期绑定于
variant本身，别保存或跨作用域使用 - 对
const variant调用会返回const T*，类型需严格匹配 cv 限定符
如何正确判断并访问 variant 中的某个类型？
核心就是「先判空，再解引用」两步，中间不能跳过空指针检查。很多人写成 if (auto p = std::get_if<int>(&v)) { use(*p); }</int> 是对的；但写成 if (std::get_if<int>(&v)) { use(*std::get_if<int>(&v)); }</int></int> 就重复调用了两次 —— 效率低，且可能因并发修改导致二次调用返回 nullptr，解引用崩溃。
使用场景：解析配置项、状态机跳转、协议字段分发等需要按类型分支但不想用 std::visit 的扁平逻辑。
立即学习“C++免费学习笔记（深入）”；
- 每个
std::get_if<t></t>只能检测一种确切类型，不支持继承关系或模板通配 - 如果
variant含多个同类型（如std::variant<int int></int>），行为未定义 —— 标准禁止这种定义 - 注意
std::monostate：可用std::get_if<:monostate>(&v)</:monostate>检查是否为空状态
std::get_if 在嵌套 variant 或自定义类型中要注意什么？
它只做顶层类型匹配，不递归展开。比如 std::variant<int std::variant bool>></int> 中，std::get_if<double>(&v)</double> 永远返回 nullptr，因为外层 variant 当前持的是内层 variant 对象，不是 double。
性能影响：std::get_if 是 O(1) 时间复杂度，但每次调用都会读取 variant 内部的 type index 并做整数比较，频繁多路分支建议改用 std::visit + overloaded 结构更清晰。
- 自定义类型需满足可复制/可移动，否则
std::get_if编译失败（因内部可能涉及隐式转换或构造） - 若类型含私有成员或删除了拷贝构造，
std::get_if仍可工作（它只取地址，不构造新对象） - 对齐差异可能导致指针解引用时触发未定义行为 —— 确保目标类型在该平台上的对齐要求被满足（通常编译器自动保证）
替代方案对比：std::get_if vs std::holds_alternative vs std::visit
std::holds_alternative<t>(v)</t> 只判断类型存在性，不提供访问入口；std::visit 更适合多类型统一处理，但引入额外函数对象开销和语法噪音。三者不是互斥，而是分工明确。
容易踩的坑：有人用 std::holds_alternative 判断后再用 std::get，看似安全，实则存在竞态窗口 —— 多线程下 variant 可能在两次调用之间被修改，导致 std::get 崩溃。
- 单类型、单次访问 → 无条件用
std::get_if - 只判断不访问 → 用
std::holds_alternative（轻量） - 需处理全部分支或类型数量动态增长 → 优先
std::visit - 禁用异常 + 需要访问 + 类型已知 →
std::get_if是唯一合理选择
最易被忽略的一点：std::get_if 的模板参数必须是 variant 的一个合法备选项类型，哪怕它只是 typedef 别名，也必须和声明时完全一致（包括 const/volatile 修饰），否则编译失败而非运行时返回 nullptr。