std::aligned_storage 是编译期生成的未初始化对齐缓冲区，专为 placement new 提供合规内存，不管理生命周期，C++23 已弃用，应改用 std::aligned_storage_t 或 alignas(std::byte)。
std::aligned_storage 本质是编译期对齐占位符
std::aligned_storage 不分配内存，也不管理对象生命周期，它只在编译期生成一个 足够大且满足指定对齐要求的未初始化字节缓冲区。它的底层用途非常具体：为 placement new 提供合规的原始内存地址 —— 即确保该地址能安全承载指定类型（如 std::string、std::vector）的对象实例。
常见错误现象：直接用 char buf[sizeof(T)] 做 placement new 目标，但 buf 的地址可能不满足 T 所需的对齐（例如 alignof(__m256) = 32），导致未定义行为（SIGBUS 或静默数据损坏）。
- 它不等价于
std::aligned_alloc（后者是运行时堆上对齐分配） - 它不自动调用构造/析构；你必须显式用
new (ptr) T{...}和ptr->~T() - C++23 起已弃用，推荐改用
std::aligned_storage_t别名或更现代的std::byte[N]+std::assume_aligned
典型使用场景：实现简易 variant 或对象池
当你需要在固定大小缓冲区中“复用内存”存放不同类型的对象（比如 int、std::string、MyHeavyStruct），又不想依赖堆分配时，std::aligned_storage 是构建这种 union-like 存储的基础。
关键点在于：必须按所有可能类型的 最大对齐 和 最大尺寸 来配置 std::aligned_storage：
立即学习“C++免费学习笔记（深入）”；
struct MyVariant {
// 支持 int（align=4）、std::string（align=8）、MyVec（align=32）
using storage_t = std::aligned_storage_t;
alignas(alignof(std::string)) char data[sizeof(std::string)];
template
void emplace(T&& t) {
new (data) std::remove_reference_t(std::forward(t));
}
};
注意：alignas 修饰 data 是冗余的（std::aligned_storage_t 已保证），但显式写出可增强可读性；真正不可省的是对齐值必须 ≥ 所有候选类型的 alignof。
为什么不能只靠 sizeof + alignof 手算？
手动计算看似可行，但容易忽略 ABI 细节：
- 某些平台（如 ARM64）对
long double或向量类型要求严格对齐，而sizeof(T)可能掩盖 padding 分布 - 编译器可能因结构体内嵌或 ABI 要求，在
struct末尾插入额外 padding，使实际所需缓冲区 >sizeof(T) -
std::aligned_storage内部会做保守对齐扩展（例如：请求 16 字节对齐 + 20 字节大小，可能返回 32 字节缓冲并确保起始地址 %32 == 0）
所以即使你知道 T 的 sizeof 和 alignof，仍应优先用 std::aligned_storage_t —— 它封装了编译器对齐策略，比手写 alignas(N) char buf[M] 更可靠。
替代方案与迁移建议
C++17 起，std::aligned_storage 已被标记为 deprecated；C++23 正式移除。当前更推荐的做法是：
- 用
std::aligned_storage_t（它是std::aligned_storage的别名，更简洁）::type - 对简单 case，直接用
alignas(A) std::byte buf[N]，再配合std::launder和std::assume_aligned - 若需动态对齐（如运行时才知道对齐值），必须用
std::aligned_alloc/_aligned_malloc等系统 API
真正容易被忽略的是：无论用哪种方式，只要做了 placement new，就必须严格配对调用析构函数 —— 编译器不会帮你做，漏掉就会导致资源泄漏（如 std::string 内部堆内存未释放）。
