destroy_n：别再手动写循环析构前N个对象了

你有没有写过这样的代码？

for (size_t i = 0; i < n; ++i) {
    ptr[i].~T();
}

一行注释写着“手动析构前n个对象”，心里却隐隐发虚——万一T是std::string，析构抛异常怎么办？万一ptr指向的是std::vector<int>的内部缓冲区，而n超了实际构造数量呢？更糟的是，这段代码在C++17里还能凑合，在C++20里，它已经不是“不够优雅”，而是语义不完整了。

std::destroy_n 就是来收编这类野路子的。

它不是语法糖，也不是可有可无的封装。它是C++17正式引入的、唯一被标准认可的批量析构原语，专为“已构造但未析构”的对象区间设计。它的存在，意味着你终于可以告别手写析构循环，也终于能和std::uninitialized_construct_n、std::uninitialized_move_n站在同一语义平面上——构造、移动、析构，三者终于对称了。

destroy_n 的签名很干净：

template<class ForwardIterator>
ForwardIterator destroy_n(ForwardIterator first, size_t n);

它接收一个迭代器起点和数量n，依次调用[first, first + n)范围内每个对象的析构函数，并返回first + n。注意：它不释放内存，只负责析构；它不检查n是否越界，但会要求first + i（i < n）始终是合法可解引用的迭代器——这和std::uninitialized_*系列一脉相承：责任边界清晰，不越俎代庖。

真正容易踩坑的地方，不在语法，而在使用前提。

它只对“已成功构造”的对象有效。如果你用operator new[]分配了一块裸内存，又只调用了前3个对象的new (ptr + i) T{}，那destroy_n(ptr, 5)就是未定义行为——后两个根本没构造过，哪来的析构？这时候必须严格匹配构造数量，就像你不会给没点的外卖打五星一样。

另一个常被忽略的细节：异常安全性。destroy_n本身不声明noexcept，因为析构函数可能抛异常（虽然不推荐，但标准允许）。如果第4个对象析构时抛了std::bad_alloc，前3个已经析构完毕，无法回滚。所以实践中，若T的析构函数可能抛异常（比如某些带日志清理逻辑的类），你应该自己加try/catch包裹，或者——更推荐——把析构逻辑改造成noexcept。这不是教条，而是让destroy_n真正可控的前提。

实际用在哪？三个典型场景最能体现它的不可替代性。

场景一：自定义容器的clear()实现
比如你正在写一个简易small_vector<T, N>，内部用aligned_storage_t<sizeof(T), alignof(T)>做栈上缓冲。clear()不能直接delete[]——内存根本没new过。正确做法是：记录当前size_，然后std::destroy_n(data_, size_)，再置size_ = 0。析构数量必须等于实际构造数量，不多不少。

场景二：std::vector扩容时的老数据迁移
vector realloc前，要把旧空间里的对象移到新空间。移动完成后，旧空间的对象必须析构。这时destroy_n(old_begin, old_size)比手写循环更可靠——它复用标准库对迭代器类型、SFINAE、ADL的支持，连std::unique_ptr这种特殊析构语义都自动适配。

场景三：std::pmr::polymorphic_allocator配合使用
当你用多态内存资源管理对象生命周期时，destroy_n是唯一能和construct_n配对的析构接口。手写循环在这里会丢失allocator的析构钩子（比如polymorphic_allocator::destroy），导致资源泄漏。

顺带提一句：别试图用destroy_n去“修复”未定义行为。比如有人想用它清理std::vector的data()——不行。vector的data()指向的是由vector内部管理的内存，其对象生命周期完全由vector控制，擅自析构等同于拔掉别人的氧气管。

最后说个实在建议：如果你的代码库里还有手写析构循环，不妨花五分钟改成destroy_n。改完之后，不仅行数少了，更重要的是——你向自己确认了一件事：这段析构逻辑，现在和标准库站在同一抽象层级上。它不再是个临时补丁，而是一个有明确契约、有标准背书、能经得起-D_GLIBCXX_DEBUG检验的操作。

析构不是收尾工作，而是对象生命周期里最需要被认真对待的一环。destroy_n不炫技，不讨巧，就老老实实做一件事：安全、一致、可组合地结束N个对象的生命。用它，不是为了赶时髦，而是终于能把这件小事，做得像标准库期待的那样稳。