C++现代工厂模式：make_unique/make_shared为何优于new？【异常安全】

make_unique和make_shared通过原子化内存分配与构造、RaiI自动清理，避免异常导致的资源泄漏；且make_shared合并控制块与对象内存，减少一次分配。

为什么 make_unique 和 make_shared 能避免资源泄漏？

因为 new 表达式本身不提供异常安全保证——当构造函数抛出异常时，已分配但未管理的裸指针会直接丢失，导致内存泄漏。

而 make_unique 和 make_shared 是原子操作：内存分配和对象构造在单个函数调用内完成，且内部使用 RAII 包装；一旦构造失败，它们会自动释放已分配内存。

• std::unique_ptr p(new T(args...))：先 new T，再构造 unique_ptr；若 unique_ptr 构造中途（如移动赋值）抛异常，T 的内存就泄漏了
• auto p = std::make_unique(args...)：整个过程在一个函数内，无中间裸指针状态
• 同理适用于 make_shared，它还额外把控制块和对象内存合并分配，减少一次堆分配

make_shared 比 shared_ptr + new 少一次内存分配

shared_ptr 需要两块独立内存：一块存对象，一块存引用计数控制块。手动用 new 构造时，这两块必须分别申请。

make_shared 把对象和控制块布局在同一块连续内存里，仅需一次 malloc（或 operator new），提升缓存局部性并降低开销。

立即学习“C++免费学习笔记（深入）”；

• 典型场景：auto sp = std::make_shared<:vector>>(1000) → 1 次分配
• 等价手动写法：std::shared_ptr<:vector>> sp(new std::vector(1000)) → 至少 2 次分配（对象 + 控制块）
• 注意：make_shared 不支持自定义删除器（custom deleter），此时只能退回到 shared_ptr + new

哪些情况不能用 make_unique/make_shared？

不是所有构造场景都适用，硬套反而引发编译错误或语义偏差。

• 类有私有/删除的构造函数，且未将 make_* 声明为友元（罕见但存在）
• 需要传递自定义删除器：std::unique_ptr → 只能用 std::unique_ptr(new Foo)
• 想用 std::shared_ptr 管理已有裸指针（如 C API 返回的指针）→ 必须用 shared_ptr 构造函数，无法用 make_shared
• make_shared 无法调用 std::initializer_list 构造函数（c++17 前），例如 std::make_shared<:vector>>({1,2,3}) 会失败；需改用 std::shared_ptr<:vector>>(new std::vector{1,2,3})

异常安全的典型反例：多个 make_* 参数传入同一函数时

即使每个 make_unique 单独是异常安全的，多个一起作为函数参数时，C++ 不规定求值顺序，仍可能泄漏。

void process(std::unique_ptr, std::unique_ptr); process(std::make_unique(), std::make_unique()); // ❌ 危险！