std::variant能安全替代裸union，因其通过RAII自动管理构造/析构并强制类型检查；裸union因标签与内存脱钩易致未定义行为、泄漏或崩溃。
std::variant 能安全替代裸 union 处理多类型节点，但不是“开箱即用”的无缝替换——它强制你面对类型流转逻辑，把隐式风险转为显式检查。
为什么裸 union 在节点场景里特别危险
处理 AST、配置项、协议字段这类“非此即彼”的节点时，裸 union 往往搭配一个 enum 标签手动管理活跃类型。问题在于：这个标签和内存实际内容完全脱钩。
- 写入
std::string后忘了调用其构造函数 → 读取时触发未定义行为（比如.c_str()访问野指针） - 析构前没手动调用
~string()→ 内存泄漏，且后续再次写入可能覆盖残留堆指针 - 标签值被意外修改（如越界写、未初始化）→
switch分支走错，reinterpret_cast强转后解引用崩溃
std::variant 把这套易错的手动流程收进 RAII：构造时自动调用对应类型的构造函数，析构时自动调用对应析构函数，访问前用索引比对类型——错一次就抛 std::bad_variant_access，而不是静默崩坏。
std::get 与 std::get_if 的真实分工
别把 std::get 当成“取值工具”，它是“断言型操作”；std::get_if 才是“探测型操作”。混用会掩盖设计缺陷。
- 用
std::holds_alternative+(node) std::get—— 适合分支少、逻辑确定的场景（如解析器已知当前 token 是整数字面量）(node) - 用
auto* p = std::get_if，判空后解引用 —— 适合需要轮询多个类型的 dispatch（如遍历节点树统一做数值转换）(&node) - 绝对不要对
std::get包一层(v) try/catch来“兜底”——这说明你根本没理清节点类型流转路径，该重构状态机或加校验入口
std::visit 不是语法糖，是类型分发的基础设施
std::visit 的核心价值不是“写起来短”，而是它天然拒绝漏处理——编译器能检查 lambda 是否覆盖了 std::variant 的所有可选项（配合 -Wunhandled-exception 或 Clang 的 -Wcovered-switch-default）。
- 用
if constexpr分支时，注意std::decay_t才是真实类型，别漏掉const或引用修饰 - 若节点类型含
std::monostate（如std::variant<:monostate int std::string>），必须显式处理该分支，否则std::visit在空状态下调用会抛异常 - 避免在 visitor 里做耗时操作（如字符串拼接、IO）——
std::visit是 inline 友好的，但副作用会破坏缓存局部性
默认构造和空状态的陷阱
std::variant 默认构造的行为取决于首类型：如果第一个类型可默认构造（如 int），那 v{} 就初始化为那个类型；如果首类型不可默认构造（如 std::string_view），则整个 std::variant 不可默认构造。
- 想让节点支持“未初始化”语义？显式加上
std::monostate并放首位：std::variant<:monostate int double std::string> - 检查是否为空：用
v.index() == 0（当std::monostate是首类型时），而不是std::holds_alternative<:monostate>(v)—— 前者是 O(1) 索引查，后者要遍历类型列表 - 别依赖
v.valueless_by_exception()判断业务空状态——它只表示因异常导致构造失败，不是设计上的“空”
最常被忽略的一点：当你把 std::variant 放进 std::vector 或作为类成员时，它的拷贝/移动语义由内部活跃类型决定，而 std::variant 自身不提供 noexcept 保证——若其中任一类型移动构造可能抛异常，整个 std::variant 移动就不 noexcept，会影响容器扩容等行为。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
