是的，std::unique_ptr能管理动态数组。1. std::unique_ptr
能。
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<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
管理动态数组时需要注意哪些陷阱？
即便有了
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
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
极大地简化了动态数组的内存管理，让程序员可以更专注于业务逻辑，而不是在底层内存管理上反复踩坑。这不仅提升了代码的健壮性，也显著提高了开发效率。
