std::variant比C风格union更安全，因其是类型安全的标签联合，内置运行时类型标识，非法访问抛std::bad_variant_access异常；而C union无类型记录，读错类型触发未定义行为。
std::variant 为什么比 C 风格 union 更安全？
C 风格 union 允许你在同一块内存里存放不同类型的值，但不记录当前实际存的是哪个类型——读错类型（比如存了 int 却按 float 读）会触发未定义行为，编译器几乎不检查。而 std::variant 是类型安全的“标签联合”（tagged union），它内部自带一个运行时标识（index 或 type info），所有访问都强制校验，访问非法状态会抛出 std::bad_variant_access 异常。
如何正确定义和初始化 std::variant？
定义时明确列出所有允许的类型，顺序影响 index() 返回值；初始化必须指定其中一个合法类型，不能留空或默认构造（除非某个类型本身可默认构造）：
std::variant<int std::string double> v1 = 42; // OK：推导为 int
std::variant<int std::string double> v2{"hello"}; // OK：推导为 std::string
std::variant<int std::string double> v3; // 编译错误：没有默认构造器
std::variant<:monostate int std::string> v4; // OK：std::monostate 提供默认状态</:monostate></int></int></int>
-
std::monostate是个空类型，专用于让std::variant可默认构造，且v4.index() == 0表示“未赋值” - 类型列表中重复类型（如
int, int）会导致编译失败 - 类型必须满足可析构、可移动（或可复制），含引用或抽象类会编译报错
怎么安全地读取 std::variant 的值？
绝不能直接转型或指针强转——必须用 std::get 或 std::visit。前者适合你知道当前类型（运行时断言），后者适合处理多种可能类型：
Web Accessibility (WCAG 2 AA))
下载
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
std::variant<int std::string> v = "test";
// 方式一：已知类型，用 std::get（失败时抛 std::bad_variant_access）
try {
std::string& s = std::get<:string>(v); // OK
int& i = std::get<int>(v); // 抛异常：当前不是 int
} catch (const std::bad_variant_access&) { }
// 方式二：泛化处理，用 std::visit（推荐）
std::visit([](const auto& x) {
using T = std::decay_t<decltype>;
if constexpr (std::is_same_v<t int>) {
std::cout ) {
std::cout <ul>
<li>
<code>std::get<type>(v)</type></code> 和 <code>std::get<index>(v)</index></code> 都会检查当前 <code>index()</code>，不匹配就抛异常</li>
<li>
<code>std::visit</code> 要求 lambda 支持所有变体类型；<code>constexpr if</code> 是处理异构逻辑最清晰的方式</li>
<li>避免用 <code>std::holds_alternative<t>(v)</t></code> + <code>std::get<t></t></code> 组合——两次检查冗余，且中间可能被修改（多线程下更危险）</li>
</ul>
<h3>替换 union 时要注意哪些坑？</h3>
<p>看似只是把 <code>union</code> 换成 <code>std::variant</code>，但语义和内存布局完全不同：</p>
<ul>
<li>
<code>std::variant</code> 的大小 ≥ 最大成员大小 + 少量 tag 开销（通常 1–8 <a style="color:#f60; text-decoration:underline;" title="字节" href="https://m.php.cn/zt/16298.html" target="_blank">字节</a>），不是严格等于最大成员；而 C <code>union</code> 精确对齐到最大成员</li>
<li>
<code>std::variant</code> 不支持 POD 类型的位域、结构体内嵌 union 等底层操作；不能用 <code>reinterpret_cast</code> 或 memcpy 操作其内部存储</li>
<li>如果原 <code>union</code> 里有非 trivial 析构类型（如 <code>std::string</code>），C 风格写法本就危险；<code>std::variant</code> 会自动管理生命周期，但你要确保所有类型都满足 <code>std::is_trivially_destructible</code> 以外的约束（例如移动构造）</li>
<li>性能敏感场景（如高频循环中），<code>std::visit</code> 有间接调用开销，<code>std::get</code> 有分支检查——若 99% 情况是同一类型，可先用 <code>index()</code> 分支预判，再 <code>std::get</code>
</li>
</ul>
<p>真正难的不是语法替换，而是厘清“这个 union 原本靠什么保证类型正确”——是靠协议？靠外部 flag？还是靠程序员记忆？<code>std::variant</code> 把隐式契约变成显式约束，这一步设计没想清楚，后面照样出错。</p></t></decltype></int></:string></int>
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
