使用std::make_shared更高效，因它合并对象和控制块的内存分配为一次，减少开销并提升异常安全性；而用new构造需两次分配，性能更低且有泄漏风险。
直接使用
std::make_shared通常更高效，因为它能减少一次内存分配。它将对象本身和 shared_ptr 的控制块（引用计数等信息）分配在同一块连续的内存中。
std::make_shared 通常是首选的 shared_ptr 构造方法，因为它具有性能优势和异常安全性。
为什么使用 new
构造 shared_ptr
会降低性能？
当你使用
new分配对象，然后用这个指针构造
shared_ptr时，实际上发生了两次内存分配。第一次是为对象本身分配内存，第二次是为
shared_ptr的控制块分配内存。
std::make_shared将这两者合并为一次分配，减少了内存分配的开销，也减少了内存碎片化的可能性。想象一下，你搬家，
std::make_shared就像一次性打包所有东西，而
new分配再构造就像先搬家具，再搬杂物，费时费力。
更具体地说，控制块包含了引用计数、weak count（用于
weak_ptr）以及可能的自定义删除器。这些信息对于
shared_ptr的正常工作至关重要。
std::make_shared
如何提高异常安全性？
考虑以下代码：
process_widget(std::shared_ptr(new Widget), function_that_might_throw());
如果
new Widget成功执行，但
function_that_might_throw()抛出了异常，那么
new Widget返回的指针将会泄漏，因为
shared_ptr还没有构造成功。
使用
std::make_shared可以避免这个问题：
process_widget(std::make_shared(), function_that_might_throw());
std::make_shared在一次操作中完成对象的分配和
shared_ptr的构造，要么全部成功，要么全部失败，从而保证了异常安全性。
std::make_shared
有什么缺点吗？
虽然
std::make_shared优点很多，但也有一些情况下不适合使用。
自定义删除器： 如果你需要使用自定义删除器，并且删除器的大小很大，那么将其存储在控制块中可能会造成额外的内存开销。在这种情况下，使用
new
分配对象，然后使用自定义删除器构造shared_ptr
可能更合适。内存占用： 当
weak_ptr
指向由std::make_shared
创建的对象时，即使所有shared_ptr
都被销毁，控制块仍然存在，直到所有weak_ptr
也被销毁。这意味着对象占用的内存可能无法立即释放。不过，这通常不是一个严重的问题，除非内存资源非常有限。不完全类型：
std::make_shared
需要在调用时知道模板参数的完整类型。如果你的类是不完全类型（例如，只有声明而没有定义），则不能使用std::make_shared
。
总的来说，
std::make_shared是一种优秀的
shared_ptr构造方式，但在特定情况下需要权衡其优缺点。通常情况下，优先使用
std::make_shared是一个好的习惯。
