std::make_shared 更高效因一次分配同时创建控制块和对象，避免两次分配开销；适用于非数组、无自定义删除器、构造不抛异常的类型，支持完美转发但不支持向下转型。
std::make_shared 为什么比 new + std::shared_ptr 构造更高效
因为 std::make_shared 在一次内存分配中同时构造控制块（control block）和对象本身，而 new T + std::shared_ptr<t>(new T)</t> 需要两次独立分配：一次给对象，一次给控制块。这对小对象尤其明显——减少分配次数 = 减少系统调用开销 + 更好缓存局部性。
注意：这种优化仅在对象类型不为数组、不含自定义删除器、且构造函数不抛异常（或已处理）时稳定生效。
- 控制块包含引用计数、弱引用计数、删除器等元数据，大小固定但不可忽略（通常 16–32 字节）
- 若对象本身只有几个字节（如
int、std::pair<int char></int>），两次分配的开销可能超过对象本身的内存占用 - 使用
std::make_shared后，对象与控制块大概率位于同一 cache line，降低 false sharing 风险
std::make_shared 的正确调用方式与常见误用
必须严格匹配目标类型的构造函数签名；不能用于需要自定义删除器或分配器的场景；不支持数组类型（C++20 前）。
auto p1 = std::make_shared<std::string>("hello"); // ✅ 正常构造
auto p2 = std::make_shared<std::vector<int>>(10, 42); // ✅ 带参数构造
auto p3 = std::make_shared<int>(123); // ✅ 内置类型也支持
<p>// ❌ 错误：无法传入自定义删除器
// auto p4 = std::make_shared<FILE>(fopen("x.txt", "r"), [](FILE* f) { fclose(f); }); // 编译失败</p><p>// ✅ 替代写法（必须用裸指针构造）
auto p4 = std::shared_ptr<FILE>(fopen("x.txt", "r"), [](FILE* f) { fclose(f); });</p>- 所有参数都会被完美转发（perfect forwarding），所以
std::move、左值引用、初始化列表都可直接传递 - 若类有 explicit 构造函数，
std::make_shared仍可调用（它不涉及隐式转换） - 不要试图对继承体系做“向下转型”后再用
make_shared：它返回的是确切模板类型，不是基类指针
如何实测 make_shared 与手写 new 的性能差异
关键不是看单次耗时，而是看大量短生命周期对象下的分配吞吐量与内存碎片趋势。推荐用 std::chrono::high_resolution_clock + 循环 10⁵~10⁶ 次，并禁用 ASLR 和 malloc 调试模式（如 Linux 下避免 export MALLOC_CHECK_=1）。
立即学习“C++免费学习笔记（深入）”；
void benchmark_make_shared() {
constexpr size_t N = 100000;
auto start = std::chrono::high_resolution_clock::now();
for (size_t i = 0; i < N; ++i) {
auto p = std::make_shared<std::complex<double>>(i, i * 2.0);
}
auto end = std::chrono::high_resolution_clock::now();
auto us = std::chrono::duration_cast<std::chrono::microseconds>(end - start).count();
std::cout << "make_shared: " << us << " μs\n";
}
<p>void benchmark_raw_new() {
constexpr size_t N = 100000;
auto start = std::chrono::high_resolution_clock::now();
for (size_t i = 0; i < N; ++i) {
auto p = std::shared_ptr<std::complex<double>>(new std::complex<double>(i, i * 2.0));
}
auto end = std::chrono::high_resolution_clock::now();
auto us = std::chrono::duration_cast<std::chrono::microseconds>(end - start).count();
std::cout << "raw new: " << us << " μs\n";
}</p>- 测试时关闭编译器优化（
-O0）会掩盖真实差异，建议至少用-O2 - 观察 RSS 内存峰值：手写
new方式更容易因分配器策略导致碎片升高 - 在容器中反复创建/销毁
shared_ptr（如std::vector<shared_ptr>></shared_ptr>）时，差异更显著
什么情况下不该用 std::make_shared
当对象构造可能抛异常，且你希望控制块和对象的生命周期解耦时；或者你需要把 shared_ptr 绑定到栈对象、文件描述符、或非 new 分配的内存上。
- 栈对象绑定：
int x = 42; auto p = std::shared_ptr<int>(&x, [](int*){});</int>——make_shared无法做到 - 定制分配器：
std::make_shared不接受 allocator 参数（C++20 引入了std::allocate_shared） - 构造函数抛异常风险高，且你依赖控制块存活来记录日志：此时分开分配能确保控制块早于对象构造完成，便于异常安全清理
- 多态对象需从派生类构造后向上转型，且基类析构非 virtual：虽然罕见，但
make_shared<derived>()</derived>返回的是shared_ptr<derived></derived>，转成shared_ptr<base>后仍共享同一控制块，一般没问题；但若 Base 析构不 virtual，行为未定义 —— 这是设计问题，不是make_shared的锅
真正容易被忽略的是：std::make_shared 对齐行为由分配器决定，而默认全局 new 的对齐可能和你的 SIMD 类型要求不一致；如果对象含 alignas(32) 成员，某些旧版 libstdc++ 可能未正确对齐控制块区域，导致运行时崩溃 —— 这类边界情况需实测验证。
