shared_ptr初始化必须用make_shared，直接new构造易致内存泄漏；拷贝赋值增引用计数，归零才释放；循环引用需weak_ptr破；get()仅限C接口等极少数场景。
shared_ptr 初始化必须用 make_shared
直接用 new 构造 shared_ptr 是危险的，容易导致内存泄漏或异常安全问题。比如：shared_ptr<int> p(new int(42), [](int* p) { delete p; });</int> 看似可控，但若构造函数中抛异常（如自定义删除器抛出），new int(42) 分配的内存就没人接管了。
正确做法永远优先用 make_shared：
auto p = std::make_shared<int>(42);
auto s = std::make_shared<std::string>("hello");make_shared 一次性分配控制块和对象内存，效率更高，且天然异常安全。只有极少数场景（如需自定义删除器且无法适配 make_shared）才考虑带裸指针的构造，此时务必确保 new 和 shared_ptr 构造在同一条表达式中、无其他可能抛异常的操作干扰。
shared_ptr 的拷贝与赋值会增加引用计数
每次拷贝、赋值、作为参数传入函数（非引用）、从函数返回，都会触发引用计数 +1；离开作用域或重置时 -1。计数归零才真正释放资源。
立即学习“C++免费学习笔记（深入）”；
常见误判点：
- 以为
std::vector<:shared_ptr>></:shared_ptr>存的是“轻量指针”，其实每个元素都维护独立控制块 —— 大量拷贝仍开销可观 - 把
shared_ptr当作普通指针传递给 C 风格 API（如some_c_func(p.get())）后，忘了它不延长生命周期 —— 若原shared_ptr提前析构，get()返回的裸指针立刻悬空 - 循环引用：A 持有 B 的
shared_ptr，B 也持有 A 的shared_ptr→ 引用计数永不归零 → 内存泄漏
破循环引用必须用 weak_ptr 替换其中一端，例如：
struct Node {
std::shared_ptr<Node> next;
std::weak_ptr<Node> prev; // 不参与计数
};shared_ptr.get() 和 *p 的使用边界很窄
p.get() 只应出现在需要向遗留 C 接口传参、或调试打印地址等极少数场景。它返回的裸指针不具备所有权，也不影响引用计数 —— 不能拿它去 delete，也不能长期保存。
*p 和 p-> 是安全的解引用方式，但前提是 p 非空。访问前应检查：
if (p) {
std::cout << *p << "\n";
}不要写 if (p.get()) —— 冗余且掩盖语义；更不要依赖隐式转换（if (p) {...} 已足够）。
reset() 和赋值 nullptr 的行为差异
p.reset() 和 p = nullptr 效果相同：减少引用计数，若为 0 则释放资源，并将 p 置为空。但两者语义不同：
-
reset()更明确表示“放弃所有权”，尤其适合配合自定义删除器使用（p.reset(nullptr, my_deleter)） -
p = nullptr更符合直觉，且可链式赋值（p = q = nullptr;）
注意：p.reset(p.get()) 是严重错误 —— 先释放再用已释放的指针重新构造，未定义行为。
复杂点在于：当多个 shared_ptr 指向同一对象时，任意一个调用 reset() 或赋值 nullptr，只影响自身引用计数，不影响其他副本。真正的销毁时机由最后一个存活者决定 —— 这正是它“共享”而非“独占”的本质。
