是的，std::unique_ptr能管理动态数组。1. std::unique_ptr<t[]>是专为数组设计的特化版本，析构时自动调用delete[]，避免内存泄漏；2. 使用std::make_unique<int[]>(size)或new创建数组，必须匹配unique_ptr<t[]>类型；3. 不要混用unique_ptr<t>与数组，否则引发未定义行为；4. 注意不存储数组大小、不支持指针算术等使用限制；5. 避免release()导致的手动管理风险；6. 多态数组推荐用std::vector<std::unique_ptr<base>>管理。相比原始指针，unique_ptr通过raii机制确保资源安全释放，具备异常安全、清晰所有权语义、杜绝重复释放和悬空指针等优势，显著提升代码健壮性与开发效率。
能。
std::unique_ptr提供了专门的数组特化版本 (
unique_ptr<T[]>)，能够安全有效地管理动态分配的数组，自动处理
delete[]操作，避免了传统C++中手动管理数组内存时常见的陷阱。
解决方案
std::unique_ptr对数组的管理，关键在于其模板特化。当你声明一个
unique_ptr<T[]>类型时，它就知道自己管理的是一个数组，并在析构时调用正确的
delete[]操作符来释放内存。这与管理单个对象的
unique_ptr<T>调用
delete有着本质区别。
例如，你可以这样创建并管理一个动态整数数组：
#include <memory>
#include <iostream>
// 推荐的创建方式
std::unique_ptr<int[]> arr1 = std::make_unique<int[]>(10); // 创建一个包含10个int的数组
for (int i = 0; i < 10; ++i) {
arr1[i] = i * 10;
}
std::cout << "arr1[5]: " << arr1[5] << std::endl; // 通过 operator[] 访问元素
// 另一种创建方式（使用new，但 make_unique 更安全高效）
std::unique_ptr<double[]> arr2(new double[5]); // 创建一个包含5个double的数组
for (int i = 0; i < 5; ++i) {
arr2[i] = i * 0.5;
}
std::cout << "arr2[2]: " << arr2[2] << std::endl;
// unique_ptr 的所有权转移特性
std::unique_ptr<int[]> arr3 = std::move(arr1); // arr1 现在为空，所有权转移给 arr3
if (!arr1) {
std::cout << "arr1 is now empty after move." << std::endl;
}
std::cout << "arr3[5]: " << arr3[5] << std::endl;
// 当 unique_ptr 超出作用域时，内存会被自动释放 (调用 delete[])这种机制确保了RAII（资源获取即初始化）原则在数组管理上的应用，大大降低了内存泄漏和悬空指针的风险。
unique_ptr<T[]>
与 unique_ptr<T>
有何本质区别？
这可能是最容易让人混淆，也最致命的地方。表面上看，它们都叫
unique_ptr，但核心的差异在于它们在析构时调用的内存释放操作符。
unique_ptr<T>内部默认调用的是
delete，用于释放单个对象分配的内存。而
unique_ptr<T[]>则专门特化了析构行为，使其调用
delete[]，这正是释放数组所必需的。
如果搞错了，比如你用
unique_ptr<T>去管理一个通过
new T[N]分配的数组，那结果会是未定义行为（Undefined Behavior，简称UB）。在我的经验里，这通常表现为内存泄漏，因为
delete只会释放数组的第一个元素所占用的内存，而其余部分则会变成“孤魂野鬼”，直到程序结束。更糟的是，它可能导致程序崩溃，因为
delete试图释放一个它不该释放的内存块，或者释放方式不正确。
举个例子，下面就是个典型的错误：
// 错误示例：将数组分配给非数组特化的 unique_ptr std::unique_ptr<int> bad_ptr(new int[10]); // 编译可能通过，但运行时行为是UB // 当 bad_ptr 超出作用域时，它会调用 delete bad_ptr.get()，而不是 delete[] bad_ptr.get() // 这会导致内存泄漏，甚至程序崩溃
所以，记住这个黄金法则：如果你用
new T[N]分配了内存，就必须用
unique_ptr<T[]>来管理；如果你用
new T分配了内存，就用
unique_ptr<T>。这听起来有点教条，但却是避免很多头疼问题的关键。
使用 unique_ptr
管理动态数组时需要注意哪些陷阱？
即便有了
unique_ptr<T[]>这样的利器，在使用它管理动态数组时，还是有一些细节需要留心，避免掉进一些常见的坑。
一个常见问题是关于数组的大小。
unique_ptr<T[]>本身并不存储数组的大小信息。当你通过
std::make_unique<T[]>(size)创建数组时，你传入了大小，但这个大小并没有被
unique_ptr内部记录下来。这意味着，如果你想获取数组的长度，你需要自己额外存储这个信息，或者在设计上避免直接查询长度，转而使用迭代器或范围for循环（如果可以的话）。例如：
int array_size = 10;
std::unique_ptr<int[]> my_array = std::make_unique<int[]>(array_size);
// 你需要自己记住 array_size
for (int i = 0; i < array_size; ++i) {
my_array[i] = i;
}另一个需要注意的，是
unique_ptr<T[]>不支持指针算术，比如
my_array + 1这样的操作。如果你需要遍历数组，通常还是使用
operator[]或者
get()方法获取原始指针后进行操作。但通常，直接使用
operator[]访问元素是最安全和推荐的方式。
还有，尽管
unique_ptr提供了
release()方法来放弃所有权并返回原始指针，以及
reset()方法来释放当前资源并管理新资源，但对于数组而言，一旦
release()返回了原始指针，你就又回到了手动管理
delete[]的境地，这通常是我们要避免的。除非你确实需要将数组的所有权传递给一个C风格的API，否则尽量避免使用
release()。
最后，如果你在考虑多态数组（即一个基类指针指向一个派生类对象的数组），
unique_ptr<Base[]>配合
new Derived[N]的做法通常是不安全的。因为
delete[]在这种情况下可能无法正确调用每个派生类对象的析构函数。这通常被称为“数组切片问题”的变种，更推荐的做法是使用
std::vector<std::unique_ptr<Base>>来管理多态对象集合，每个
unique_ptr管理一个独立的派生类对象。
为什么不推荐使用原始指针管理数组，以及 unique_ptr
的优势何在？
在现代C++编程中，使用原始指针（raw pointer）来直接管理动态分配的数组，简直是给自己挖坑。我个人觉得，这几乎是所有内存相关bug的温床。最明显的问题就是内存泄漏。你
new了一个数组，就必须记得在所有可能的执行路径上
delete[]它。一旦忘记，或者在函数中途遇到异常导致
delete[]没有被执行，内存就漏了。在一个大型复杂的系统中，追踪这些泄漏简直是噩梦。
原始指针还带来了悬空指针和重复释放的问题。如果你
delete[]了一个数组，但某个地方仍然持有指向这块内存的原始指针，那么这个指针就成了悬空指针。一旦通过它访问内存，程序就可能崩溃。更糟的是，如果对同一块内存重复
delete[]，那通常也会导致程序崩溃或未定义行为。
unique_ptr的出现，就是为了解决这些痛点。它的优势在于：
-
RAII 范式： 这是其核心。
unique_ptr
将资源的生命周期与对象的生命周期绑定。当unique_ptr
对象被销毁时（比如超出作用域），它会自动调用delete[]
释放其管理的数组内存。你不需要手动去记忆何时何地释放内存。 -
异常安全： 这一点至关重要。如果在
new
之后、delete[]
之前发生了异常，原始指针会导致内存泄漏。而unique_ptr
无论是否发生异常，都能保证在它被销毁时（通过栈展开等机制）正确释放内存。 -
清晰的所有权语义：
unique_ptr
明确表示它拥有其指向的资源，并且是独占所有权。这意味着同一时间只有一个unique_ptr
可以管理特定的内存块。通过std::move
可以安全地转移所有权，这让代码的意图更加清晰，也避免了多重释放的问题。 -
避免常见错误： 它强制你使用正确的
delete[]
方式，避免了delete
与delete[]
的混淆。它也从设计上避免了悬空指针和重复释放的风险，因为一旦所有权转移或资源被释放，原始unique_ptr
就会变为空。
总的来说，
unique_ptr极大地简化了动态数组的内存管理，让程序员可以更专注于业务逻辑，而不是在底层内存管理上反复踩坑。这不仅提升了代码的健壮性，也显著提高了开发效率。
