std::unique_ptr<T[]> 是管理动态数组的唯一安全方式，必须显式使用数组特化版本，否则析构时调用 delete 而非 delete[] 导致未定义行为；推荐用 std::make_unique<T>(n) 初始化，通过 operator[] 访问元素，避免裸指针运算。
std::unique_ptr 的声明和初始化必须匹配数组类型
直接用 std::unique_ptr<int></int> 持有 new int[10] 是未定义行为——析构时调用的是 delete 而非 delete[]，内存不会被正确释放。必须显式使用数组特化版本：std::unique_ptr<int></int>。
常见错误现象：程序看似正常运行，但 valgrind 报「mismatched free() / delete / delete[]」；或在 debug 模式下触发断言失败。
-
std::unique_ptr<int> ptr(new int[5]);</int>✅ 正确 -
std::unique_ptr<int> ptr(new int[5]);</int>❌ 危险，析构崩坏 - 推荐用
std::make_unique<int>(n)</int>替代裸 new（C++14 起支持）
访问数组元素不能用 *ptr 或 ptr.get() + offset 算术
std::unique_ptr<t></t> 重载了 operator[]，但没重载 operator*（因为对数组取 * 没意义），也不鼓励手动算指针偏移——这绕过了 unique_ptr 的所有权语义，且容易越界。
正确做法是直接用下标访问：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
auto ptr = std::make_unique<int[]>(3); ptr[0] = 10; ptr[1] = 20; ptr[2] = 30; // ptr.get()[1] 虽然语法合法，但属于“脱管访问”，失去 RAII 保护
- 不要对
ptr.get()做指针运算传给其他函数，除非你明确放弃管理权并手动保证生命周期 - 需要传递给 C API？用
ptr.get()是安全的，但确保该 API 不会存储该指针或试图 delete 它
std::unique_ptr 不支持自定义删除器的简写形式
普通 std::unique_ptr<t></t> 可以写成 std::unique_ptr<t mydeleter></t>，但数组版本的删除器类型必须是 std::default_delete<t></t> 的特化，不能随意替换。如果你真要自定义（比如用 free 配合 malloc），得显式指定完整类型：
auto ptr = std::unique_ptr<int[], void(*)(int*)>(
static_cast<int*>(malloc(10 * sizeof(int))),
[](int* p) { free(p); }
);
- 默认情况下，
std::unique_ptr<t></t>内置使用std::default_delete<t></t>，它等价于delete[] - 自定义删除器必须是可调用对象，且签名需匹配
void(T*)，T 是数组元素类型（不是 T[]） - 这种写法易错，除非对接 C 库，否则优先用
std::make_unique
和 std::vector 比，什么时候该选 std::unique_ptr
绝大多数场景下，std::vector 更安全、功能更全（自动扩容、迭代器、算法兼容）。但 std::unique_ptr<t></t> 的存在价值在于：零开销、无额外成员、严格只管理原始内存块，适合高性能或嵌入式约束场景。
- 你需要一个不可重分配、大小固定、不带容量/大小元数据的裸数组视图
- 你在封装底层资源（如 GPU 缓冲区映射内存），需要精确控制分配/释放方式
- 你正在写泛型代码，且必须与 C 接口保持 ABI 兼容（
std::vector对象不可按值传给 C） - 别为了“看起来更现代”而替换 vector——它不提供 move-only 语义优势，反而丢失 size()/data() 之外的所有便利
数组版 unique_ptr 的核心契约很简单：只管一块 new[] 出来的内存，不多不少。一旦需求超出这个边界，就该换工具了。
