std::make_shared 能减少内存泄漏风险，因为它将对象和控制块的分配合并为一次原子操作，异常时二者同时释放；而直接 new 配合 shared_ptr 构造函数是两次独立分配，中间异常会导致已分配对象无法接管而泄漏。
std::make_shared 为什么能减少内存泄漏风险
直接用 new 配合 std::shared_ptr 构造函数（如 std::shared_ptr<t>(new T)</t>）时，若构造过程中抛出异常，new 分配的内存可能无法被 shared_ptr 接管，导致泄漏。而 std::make_shared 把对象构造和控制块（control block）分配合并为一次堆分配，且保证二者原子性：要么全部成功，要么都不发生——异常安全得到保障。
内存布局差异直接影响异常安全性
std::make_shared 在同一块连续内存中同时存放控制块和对象，而手动 new 是两次独立分配：一次给对象，一次给控制块。这意味着：
- 手动方式中，若
new T()成功但控制块分配失败（例如内存不足），已分配的T无法自动释放 -
std::make_shared即使在T的构造函数抛异常，控制块和对象的内存也由内部统一管理，不会泄漏 - 这种布局还带来缓存友好性提升，但主要优势仍是异常安全
哪些场景下 std::make_shared 不能替代 new
不是所有情况都能用 std::make_shared 替代 new：
- 类定义了
private或deleted的构造函数，且未将std::make_shared声明为友元（C++17 起部分编译器放宽，但仍非标准保证） - 需要自定义删除器（deleter）且该删除器不能通过默认参数传递（
std::make_shared不接受自定义 deleter） - 需要构造非默认可构造类型，且参数是右值引用或涉及完美转发边界（某些老旧编译器对参数展开支持不完整）
- 继承体系中需调用派生类特定构造逻辑，而基类无合适构造签名匹配
auto ptr1 = std::make_shared<std::string>("hello"); // 安全：一次分配，异常安全
auto ptr2 = std::shared_ptr<std::string>(new std::string("hello")); // 危险：两步分配，中间可能异常
性能与兼容性要注意的细节
std::make_shared 的单次分配虽快，但注意：
立即学习“C++免费学习笔记（深入）”；
- 它会为控制块预留额外空间（通常 16–32 字节），即使对象很小，也会占用至少一页内存；对大量小对象（如
int）可能浪费空间 - 在 C++11 中，
std::make_shared对参数是完美转发，但某些编译器对初始化列表（{...}）支持不一致，建议显式构造临时对象再传入 - 若对象类型重载了
operator new，std::make_shared不会调用它——它始终使用全局::operator new分配控制块+对象内存
new，只要用了 std::shared_ptr<t>(new T(...))</t> 这种形式，就仍处于异常泄漏风险区。是否安全，不取决于有没有裸指针变量，而取决于分配与所有权绑定是否原子。 
