std::aligned_union被弃用是因为它仅提供对齐内存缓冲区，不管理对象生命周期，易引发未定义行为；C++20中移除，推荐用std::variant、std::any或std::aligned_storage_t替代。
std::aligned_union 在 C++17 中已被弃用，C++20 中彻底移除。它从未真正实现“类型安全的 union”，只是提供了一块满足对齐与尺寸要求的原始内存缓冲区——和 std::aligned_storage 类似，但多一个 alignof 计算逻辑。
为什么需要 std::aligned_union？（底层动机）
手动管理 union 时，若其中成员类型对齐要求不同（如 double 要求 8 字节对齐，long long 可能要 16 字节），直接用普通 char 数组做缓冲区容易因对齐不足导致未定义行为（UB），尤其在启用严格别名检查或使用 __builtin_assume_aligned 的编译器下。
std::aligned_union 的唯一作用就是帮你算出：这个 union 所有成员中最大的 sizeof 和最大 alignof，并打包成一个带静态 alignof 的类型，方便你安全地分配原始内存。
它不构造、不析构、不跟踪当前活跃成员——完全不感知类型语义。
立即学习“C++免费学习笔记（深入）”；
std::aligned_union 怎么用？（典型写法与陷阱）
常见误用是以为它能替代 std::variant 或自动管理生命周期。实际它只生成两个东西：type（缓冲区类型）和 alignment_value（对齐值）。你仍需手动调用 placement new 和显式析构。
- 必须自己记录当前存放的是哪个类型的对象，否则
reinterpret_cast读取会触发未定义行为 - 不能直接访问 union 成员字段（它不是真正的 union 类型，而是一个
char[N]加对齐修饰） - 对齐值仅保证“足够”，但不保证“最小”；例如
aligned_union<0, int, short>::alignment_value是alignof(int)，哪怕short只要 2 字节对齐
struct A { alignas(32) char data[4]; };
struct B { double x; };
<p>// 缓冲区需容纳 A 或 B 中更大的 size，并满足二者中更大的 alignof
using buf_t = std::aligned_union<0, A, B>::type;
alignas(std::aligned_union<0, A, B>::alignment_value) char raw_buf[sizeof(buf_t)];</p><p>// 正确：显式 placement new + 显式析构
A* a_ptr = new (raw_buf) A{};
a_ptr->~A(); // 必须调用，否则资源泄漏（如果 A 有析构逻辑）</p>为什么被弃用？现代替代方案是什么？
C++17 标准意识到：这种裸缓冲区抽象太低级、易错，且和 std::variant（C++17 引入）、std::any、甚至手动 std::byte[] + std::launder 相比，既不安全也不便利。
推荐路径：
- 需要类型安全 + 自动生命周期管理 → 用
std::variant<T1, T2, ...> - 需要运行时类型擦除 → 用
std::any - 必须手控内存（如实现自定义容器或序列化缓冲区）→ 直接用
std::aligned_storage_t<N, Align>或 C++20 的std::aligned_alloc+std::launder - 所有新代码应避免依赖
std::aligned_union，连头文件<type_traits>中它的声明在 C++20 都已删除
真正难的从来不是算对齐，而是确保对象在正确时间以正确方式构造/析构——std::aligned_union 把这部分责任全甩给程序员，而现代 C++ 更倾向于把这类错误提前拦在编译期。
