std::destroy_at仅调用析构函数而不释放内存，适用于placement new、内存池等需析构与内存释放解耦的场景；delete则先析构再归还内存，混用会导致崩溃或UB。
std::destroy_at 用来做什么，和 delete 有什么区别
std::destroy_at 只调用对象的析构函数，不释放内存。它适用于 placement new 构造的对象、内存池中预分配的缓冲区、或 std::vector 等容器内部手动管理对象生命周期的场景。而 delete 会先调用析构函数，再调用 operator delete 归还内存——这对内存池来说是错的，因为内存本就不该交还给系统。
常见错误现象：std::destroy_at(&obj) 后又 delete &obj，导致重复析构或非法内存操作；或者在栈对象上误用 std::destroy_at，触发未定义行为（UB）。
- 只能用于已构造成功的对象（即其构造函数已完整执行）
- 参数必须是指向对象的指针，不能是
nullptr（否则 UB） - 对 trivially destructible 类型（如
int、struct无析构函数），std::destroy_at是空操作，但语义上仍合法
在内存池中手动销毁对象的典型流程
内存池通常用一块大内存块 + 自定义分配器管理对象。对象用 placement new 构造后，销毁阶段必须跳过 delete，只析构：
char* pool = static_cast<char*>(::operator new(4096));
MyType* obj = new (pool) MyType{42}; // placement new
// ... 使用 obj ...
std::destroy_at(obj); // ✅ 正确：仅析构
::operator delete(pool); // ✅ 内存池整体释放（非 per-object）关键点在于：析构与内存释放必须解耦。如果混用 delete obj，会尝试从 pool 地址调用 operator delete，大概率崩溃或泄漏。
立即学习“C++免费学习笔记（深入）”；
- 确保
std::destroy_at的指针地址确实对应一个已成功构造的对象 - 若对象类型有虚析构函数，
std::destroy_at仍能正确调用虚析构（依赖静态类型信息，不依赖 vptr） - 多线程环境下，需自行保证对该对象的访问已同步结束，
std::destroy_at本身不提供线程安全
为什么不能直接写 obj->~MyType()？
手动调用析构函数（obj->~MyType()）在绝大多数情况下等价于 std::destroy_at(obj)，但存在几个隐性风险：
- 模板推导失败：当
obj是const或引用类型时，std::destroy_at能正确处理，而显式析构调用可能编译失败 - 类型擦除场景下无法使用：比如你只有
void*和std::type_info，std::destroy_at无法直接用，但这是设计缺陷，应避免这种裸void*管理 - 可读性与意图表达：
std::destroy_at明确传达“这是标准规定的对象销毁协议”，比手写析构更易维护
性能上二者完全一致，生成的汇编相同；但 std::destroy_at 是 C++17 引入的标准方式，更符合现代实践。
容易被忽略的兼容性与陷阱
某些老旧代码库或自定义 allocator 可能没适配 std::destroy_at，尤其在嵌入式或 ABI 受限环境。这时候要注意：
- C++17 是硬性要求：低于 C++17 的标准库不提供
std::destroy_at，需自行实现（本质就是一行ptr->~T()） - 对 union 成员调用
std::destroy_at是未定义行为，除非你 100% 确定当前活跃成员就是该类型 - 数组对象不能直接用
std::destroy_at：必须用std::destroy(first, last)或循环调用 - 如果类重载了
operator delete且带额外参数（如[[no_unique_address]]或对齐参数），std::destroy_at不影响它——因为根本不会调用operator delete
最常出问题的地方不是语法，而是生命周期边界模糊：比如对象还在被其他模块持有指针，就调用了 std::destroy_at。这类问题不会报编译错误，运行时才崩，得靠 RAII 或引用计数兜底。
