std::shared_ptr管理数组时不能直接用默认删除器，因为其默认调用delete而非delete[]，混用将导致未定义行为（如崩溃、内存泄漏）；必须显式提供delete[]删除器，如shared_ptr p(new int[10], [](int* q) { delete[] q; })。
std::shared_ptr管理数组时为什么不能直接用默认删除器
因为 std::shared_ptr 默认用 delete 释放资源，而数组必须用 delete[]；混用会导致未定义行为（常见表现：程序崩溃、内存泄漏、堆损坏）。哪怕编译通过，运行时也可能在析构时出问题。
- 错误写法：
std::shared_ptr<int> ptr(new int[10]);</int>—— 析构时调用delete，不是delete[] - 正确前提：必须显式提供数组专用的删除器，或改用
std::vector（更推荐） - 注意：C++17 起，
std::shared_ptr<t></t>是合法类型，但删除器仍需匹配，否则照样出错
用自定义删除器正确管理原始数组
给 std::shared_ptr 绑定一个执行 delete[] 的 lambda 或函数对象，确保析构安全。
- 推荐写法（lambda 删除器）：
std::shared_ptr<int> ptr(new int[5], [](int* p) { delete[] p; });</int> - 类型要明确：若用
std::shared_ptr<int></int>，构造时仍需传删除器，否则默认删除器还是delete - 别写成
std::shared_ptr<int> ptr(new int[5]);</int>—— 这看似类型对了，但删除器没换，依然危险 - 删除器必须是可复制/可移动的，lambda 捕获为空时满足条件；捕获局部变量会引发悬空指针
std::shared_ptr 的实际使用限制
std::shared_ptr<t></t> 仅改变类型签名，不自动切换删除逻辑。它主要影响 operator[] 的可用性，但不解决根本的析构安全问题。
- 支持下标访问：
ptr[3] = 42;合法（因为类型是T[]） - 不支持
get()返回的指针做算术运算以外的操作（比如传给需要std::unique_ptr接口的函数） - 无法获取数组长度 ——
shared_ptr本身不记录 size，得额外维护 - 和
std::vector相比，缺少迭代器、容量管理、异常安全保证等，纯属“带引用计数的裸数组”
为什么多数场景该用 std::vector 而不是 shared_ptr
除非你明确需要跨作用域共享同一块原始数组指针，并且无法修改接口（比如对接 C API），否则 std::vector 更安全、更自然。
-
std::vector自动管理内存、大小、拷贝/移动语义清晰，且可通过std::shared_ptr<:vector>></:vector>实现共享 - 若需只共享数据而非整个 vector 对象，可用
std::shared_ptr包裹std::vector，再用data()拿裸指针（注意生命周期） - 混合使用容易出错：比如把
shared_ptr<int></int>的get()传给期望std::vector的函数，类型不兼容还难调试 - 性能差异几乎为零 ——
shared_ptr的控制块开销和vector的小对象优化已让两者在多数场景无实质差别
真正需要 shared_ptr 管理数组的地方极少，一旦选了就得全程盯紧删除器、类型声明和生命周期边界——稍一松懈，就是静默的内存错误。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
