不该直接用 new 配合 std::unique_ptr 构造，因异常时会导致内存泄漏；应优先用 std::make_unique（原子操作、异常安全），仅在需自定义删除器或特殊数组初始化时才显式构造。
为什么不该直接用 new 配合 std::unique_ptr 构造？
直接写 std::unique_ptr<t>(new T(args...))</t> 看似简洁，但存在异常安全漏洞：若 T 的构造函数抛异常（比如内存分配失败、初始化逻辑出错），new T(...) 已执行，但 std::unique_ptr 构造尚未开始，导致内存泄漏。
而 std::make_unique 是原子操作——它先分配内存、再就地构造对象、最后封装为 std::unique_ptr，三步要么全成功，要么在任何一步失败时自动清理已分配资源。
常见错误现象：std::unique_ptr<myclass>(new MyClass(throw_on_construct()))</myclass> 在构造抛异常后，MyClass 对象未被管理，new 返回的裸指针丢失，无法释放。
std::make_unique 不支持自定义删除器？
确实不支持。std::make_unique 只能生成使用默认删除器（delete）的 std::unique_ptr。如果你需要文件句柄、C API 资源或非 delete 释放逻辑，必须回退到显式构造：
立即学习“C++免费学习笔记（深入）”；
- 用
std::unique_ptr<t deleter>(new T, deleter)</t> - 或更安全的写法：
std::unique_ptr<t deleter>(::operator new(sizeof(T)), deleter)</t>+ placement-new（但极少需手动这么干）
注意：自定义删除器场景下，std::make_unique 不是“不能用”，而是“根本没提供接口”——这不是缺陷，而是设计取舍：它专注解决最常见、最危险的裸 new 泄漏问题。
数组类型怎么用 std::make_unique？
C++14 起，std::make_unique 原生支持动态数组，但语法和语义与普通类型不同：
-
std::make_unique<int>(10)</int>→ 创建长度为 10 的int数组，等价于new int[10]，析构时调用delete[] -
std::make_unique<int>(10)</int>→ 创建单个值为 10 的int，不是数组 - 不支持带初始值列表的数组（如
std::make_unique<int>({1,2,3})</int>），这在 C++14/17 中非法；C++20 才通过std::make_unique_for_overwrite提供零初始化数组支持
误用后果：把 std::make_unique<int>(n)</int> 当作数组分配，会导致后续越界访问且析构错误（delete vs delete[] 不匹配）。
性能差异和编译器优化影响
理论上 std::make_unique 多一层函数调用，但现代编译器（GCC 7+、Clang 5+、MSVC 2017+）在 O2/O3 下会完全内联，生成的汇编与手写 new + 构造几乎一致。
真正影响性能的是隐式转换和模板实例化开销——尤其在头文件中高频使用时，可能略微增加编译时间。但这远小于运行时泄漏风险带来的代价。
容易忽略的一点：当 T 构造函数是 explicit 且接受单参数时，std::make_unique<t>(arg)</t> 仍能正常工作，而某些手写表达式（如 {arg} 初始化）可能因隐式转换限制报错。
复杂点在于：如果 T 的构造函数有重载或模板推导歧义（比如同时接受 int 和 std::string_view），std::make_unique 同样会遇到编译失败，这时必须显式指定类型或改用 static_cast 辅助。
