shared_ptr初始化应优先用make_shared以确保异常安全和性能；避免裸指针重复构造导致double-free；循环引用需用weak_ptr打破；reset和赋值影响引用计数；跨线程时控制块线程安全但所指对象不安全。
shared_ptr 初始化必须用 new 或 make_shared
直接把裸指针传给 shared_ptr 构造函数非常危险，比如 shared_ptr<int>(new int(42))</int> 看似没问题，但一旦构造过程中抛异常（比如后续 shared_ptr 内部分配控制块失败），new int(42) 就泄露了。更安全的做法是用 make_shared：它把对象和控制块一次性分配，原子完成，不会泄露。
常见错误现象：shared_ptr 析构后内存没释放、程序崩溃在控制块访问、Valgrind 报 double-free —— 很可能是因为多个 shared_ptr 用同一个裸指针初始化，比如：
int* p = new int(10); shared_ptr<int> a(p); shared_ptr<int> b(p); // 错！a 和 b 各自管理 p，析构时两次 delete p
- 永远优先用
make_shared<t>(args...)</t>，它性能更好、异常安全 - 万不得已要用裸指针初始化时，确保只初始化一次，且不再用该指针构造其他智能指针
-
make_shared不支持自定义删除器，需要删除器时才退回到带deleter的构造函数
循环引用导致内存泄漏的典型场景
shared_ptr 通过引用计数管理生命周期，但父子对象互相持有对方的 shared_ptr 时，计数永远不为 0，对象就永远不会析构 —— 这是最隐蔽的内存泄漏来源之一，尤其在树形结构、观察者模式或回调绑定中高频出现。
例如一个 Node 类同时持有父节点和子节点的 shared_ptr：
立即学习“C++免费学习笔记（深入）”；
struct Node {
shared_ptr<Node> parent;
vector<shared_ptr<Node>> children;
};只要任意父子链形成闭环（比如 child→parent→child），整条链就锁死。
- 打破循环的标准解法是把其中一端换成
weak_ptr，比如让parent改成weak_ptr<node></node> -
weak_ptr不增加引用计数，访问前必须调用lock()转成shared_ptr，返回空说明原对象已销毁 - 注意：不能对
weak_ptr直接解引用，也不能用它初始化另一个shared_ptr（除非调用lock()）
reset() 和赋值操作对引用计数的影响
reset() 和 = 赋值都会改变当前 shared_ptr 所指向的对象，并触发旧对象引用计数减一、新对象加一 —— 但很多人忽略它们的语义差异和副作用。
比如：
shared_ptr<int> a = make_shared<int>(1); shared_ptr<int> b = a; // b 和 a 共享，计数=2 a.reset(); // a 置空，计数减为1；b 仍有效 b.reset(); // 计数减为0，内存释放
-
reset()等价于赋值一个空shared_ptr，会立即释放旧资源（如果计数归零） - 赋值操作（
=）是浅拷贝，不复制对象，只共享控制块；若右边为空，则左边也变为空 - 频繁调用
reset()可能导致控制块反复分配/释放，性能敏感路径建议复用对象或用移动语义：a = std::move(b)
跨线程使用 shared_ptr 的注意事项
shared_ptr 的控制块（含引用计数）是线程安全的，即多个线程同时读写不同 shared_ptr 实例（哪怕指向同一对象）不会导致数据竞争。但对象本身不是线程安全的 —— 这点常被混淆。
错误理解：“用了 shared_ptr 就不用加锁”，结果在多线程里并发修改它指向的 vector 或调用非线程安全成员函数，引发未定义行为。
- 控制块线程安全 ≠ 所指对象线程安全；引用计数增减原子，但对象内容需自行同步
- 若需在线程间转移所有权，优先用
std::move，避免无谓的原子计数操作 - 避免在临界区外长期持有
shared_ptr并在临界区内解引用——可能因其他线程提前释放导致空指针解引用；稳妥做法是先lock()（如果是weak_ptr）或确保生命周期覆盖整个使用区间
真正麻烦的从来不是怎么创建 shared_ptr，而是搞清谁在什么时候还持有它。引用计数像一层薄冰，踩对位置没事，一步踏错就掉进循环引用或竞态里，而且往往等程序跑几天才暴露。
