shared_ptr不能手动释放对象，其生命周期由引用计数自动管理；调用reset()或离开作用域仅减计数，仅当计数为0时内部触发delete，不可干预；误用get()+delete会导致双重释放未定义行为。
shared_ptr 不能手动释放对象，这是设计前提
shared_ptr 的核心机制就是自动管理对象生命周期，你无法像 delete 原生指针那样“手动释放”它指向的对象。调用 reset() 或让其超出作用域，只是减少引用计数；只有计数降为 0 时，delete 才会由 shared_ptr 内部触发——这个过程不可干预、不可跳过。
想提前销毁对象？只能让引用计数归零
所谓“手动释放”，实际是主动切断所有 shared_ptr 对该对象的持有关系：
- 显式调用
ptr.reset()，清空当前 shared_ptr - 确保没有其他 shared_ptr（包括被拷贝出的副本、容器里存着的、lambda 捕获的）还指向同一对象
- 注意 weak_ptr 不影响引用计数，但若它还活着，对象已被销毁后访问会得到空锁（
lock()返回空shared_ptr） - 避免循环引用：两个对象互相用 shared_ptr 持有对方，会导致计数永远不为 0；此时需用
weak_ptr打破闭环
误用 get() + delete 是严重未定义行为
以下写法绝对禁止：
std::shared_ptr<int> p = std::make_shared<int>(42); delete p.get(); // ❌ UB！对象会被 shared_ptr 再次 delete，双重释放</int></int>
原因很直接：get() 只返回裸指针，不移交所有权；shared_ptr 析构时仍会按原计划 delete 同一块内存。
如果你真需要裸指针控制权，从一开始就不该用 shared_ptr，改用 unique_ptr（可用 release() 交出所有权）或原生指针（但得自己全权负责）。
需要精细控制释放时机？考虑 custom deleter 或 unique_ptr
shared_ptr 的释放时机完全由引用计数决定，无法延迟或提前到某个特定代码点执行。如果业务逻辑要求“在某处明确销毁”，说明它不适合 shared_ptr 的语义：
- 用
unique_ptr+reset()：独占所有权，调用即释放 - 用
shared_ptr配合自定义 deleter：可把销毁逻辑封装进 deleter 函数，但触发时机仍是计数归零那一刻 - 把对象移到堆外（如内存池、对象池），用 shared_ptr 管理“句柄”而非原始对象，销毁逻辑由池统一控制
shared_ptr 的“共享”和“自动”是一体两面，想绕过自动，就得换模型——这不是限制，而是契约。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
