std::destroy_at仅调用析构函数而不释放内存，std::construct_at替代placement new实现类型安全构造；二者须配对使用且顺序固定，需确保对象已构造、内存对齐、避免重复析构或未初始化访问。
std::destroy_at 用来安全结束对象生命周期，不是“删内存”
它只调用对象的析构函数，不释放底层 raw 内存。很多人误以为它等价于 delete 或 free()，结果在后续重复析构或未初始化就访问时崩溃。
- 必须确保传入地址指向一个已构造（且未被销毁）的对象，否则行为未定义
- 对
trivially destructible类型（如int、std::array）调用它无效果，但合法 - 常见错误：在 placement new 失败后盲目调用
std::destroy_at—— 若对象根本没构造成功，就不能析构 - 典型场景：配合
std::allocator::allocate+ placement new 实现 vector-like 的动态扩容时，旧 buffer 中对象的清理
std::construct_at 替代 placement new，更类型安全
它用模板推导自动处理 cv-qualifiers 和引用折叠，比手写 new (ptr) T(args...) 少出错。尤其当 T 是引用类型或带 const/volatile 限定时，手动 placement new 容易编译失败或语义错误。
- 参数包直接转发，不支持 initializer-list 语法（即不能写
std::construct_at(p, {1,2,3})），需改用std::initializer_list构造函数显式传参 - 如果
T的构造函数抛异常，std::construct_at会传播异常，且保证不会留下半构造对象（这点和 placement new 一致） - 不能用于 union 成员的活跃对象切换 —— 它不处理 union 的 lifetime 转换规则，仍需用
std::construct_at(&u.m)配合显式 lifetime 管理
二者必须配对使用，且顺序不能反
先 std::construct_at，再 std::destroy_at；反过来或跳过任一环节，都会导致未定义行为。C++20 引入它们正是为了明确表达“对象存在性”的边界，替代容易出错的手动调用构造/析构函数。
- 常见坑：在
std::vector自定义 allocator 的deallocate里只 free 内存，忘了先遍历调用std::destroy_at—— 导致资源泄漏（如文件句柄、堆内存） - 另一个坑：用
std::construct_at构造后，又用operator delete直接释放内存 —— 忘了对象还没析构，析构函数根本没跑 - 性能上无额外开销：两者都是内联函数，编译后和手写调用构造/析构函数几乎一致
不适用于 malloc/free 分配的内存
std::construct_at 和 std::destroy_at 只管理对象生命周期，不关心内存来源。但如果你用 malloc 分配内存，必须确保该内存满足对齐要求（alignof(T)），否则行为未定义。
立即学习“C++免费学习笔记（深入）”；
- 例如：对
alignas(16) struct S { ... };，用malloc(sizeof(S))分配的内存可能只有 8 字节对齐，std::construct_at调用会 UB - 推荐搭配
std::aligned_alloc或std::allocator使用，后者内部已处理对齐::allocate - Windows 上
_aligned_malloc返回的指针，也不能直接丢给std::destroy_at—— 没问题，只要地址有效、对齐达标、对象已构造，它就能安全析构
