std::destroy：C++ 中被低估的析构“清道夫”

你有没有写过这样的代码：用 operator new 手动分配了一块原始内存，再用 placement new 构造一批对象；或者在自定义容器里管理了一段连续的 T* 内存？这时候问题来了——对象怎么安全析构？
别急着写循环调用 obj.~T()。C++17 引入的 std::destroy 系列函数，就是专为这种场景设计的“析构执行器”，但它常被当成冷门工具束之高阁，甚至被误认为只是 for 循环的语法糖。

其实不是。

std::destroy 的核心价值，不在“能用”，而在“该用”——它把析构行为从手写逻辑中解耦出来，交由标准库统一调度，自动适配 trivially destructible 类型的优化路径。

比如，对 int、std::string_view 或空基类组合体这类无析构副作用的类型，std::destroy(first, last) 在多数实现中会直接跳过逐个调用，编译期就退化为空操作。而你手写的 for (auto& x : range) x.~T(); 却可能强制触发无意义的析构调用（尤其开启 -O0 时），既低效又掩盖了类型语义。

更关键的是边界安全。std::destroy 接收的是迭代器对（或指针范围），不依赖容器大小字段，也不假设内存布局连续性——它只信任你传入的 [first, last) 语义。这意味着，哪怕你在 std::vector<std::byte> 里按偏移量手动构造了 5 个 Widget，只要能算出起始地址和末尾地址，就能用 std::destroy 精确析构其中某一段，不会多析一个，也不会漏掉一个。

实际用法很简单：

#include <memory>
#include <vector>

std::vector<std::byte> buf(1024);
Widget* ptr = new (buf.data()) Widget{42};
Widget* ptr2 = new (buf.data() + sizeof(Widget)) Widget{"hello"};

// 析构前两个对象
std::destroy(ptr, ptr + 2);

// 注意：这里不是 destroy_n(ptr, 2)，而是 destroy(ptr, ptr+2)
// 因为 destroy_n 需要明确数量，而 destroy 更贴近迭代器惯用法

有人会问：那 std::destroy_n 和 std::destroy 有什么区别？
区别很实在：destroy 基于半开区间 [first, last)，天然兼容所有标准容器的 begin()/end()；destroy_n 则适合你已知确切数量且没有现成迭代器的场景，比如从 raw pointer + count 构建的缓冲区。两者底层都做同一件事，但接口设计指向不同上下文。选哪个，取决于你手上的“线索”是什么——是两个指针？用 destroy。是一个指针加一个整数？用 destroy_n。

还有一点容易踩坑：std::destroy 只负责调用析构函数，不释放内存。它和 std::construct_at 是一对“孪生兄弟”——一个管生，一个管死，但都不碰 operator delete。这点必须刻进本能：析构完的对象，其内存仍处于“已占用但未析构”的中间态，后续要么重用（再次 placement new），要么手动 ::operator delete(ptr)。混淆这点，轻则内存泄漏，重则二次析构 UB。

顺带一提，C++20 加入的 std::destroy_at 是单点析构的快捷方式，等价于 std::addressof(obj)->~T()，但多了类型检查和 SFINAE 友好性。它不是替代品，而是补全——当你只有一个孤零零的对象引用，又不想暴露 &obj 这种潜在陷阱时，destroy_at(&obj) 更干净。

最后说个真实调试经验：有次我们在线程局部缓存里复用 std::vector<char> 当对象池，构造后忘了析构就直接 clear()，结果 std::string 成员残留的堆内存没释放，几天后 OOM。后来改成 std::destroy(pool.begin(), pool.end()) 配合 placement new，问题消失。这不是玄学修复，是让析构行为回归到内存生命周期的正轨上。

所以，下次当你面对原始内存、自定义分配器、或需要精细控制对象生命周期的场景，请把 std::destroy 从工具箱顶层拿出来。它不炫技，不抽象，就干一件事：在正确的时间、正确的范围内，把析构函数稳稳地叫醒。
这恰恰是 C++ 底层控制力最朴素也最可靠的体现——不靠魔法，靠契约；不靠猜测，靠标准。