shared_ptr初始化必须用std::make_shared或显式构造（如shared_ptr(new T)），不能用裸指针隐式转换；因引用计数机制要求资源生命周期由控制块统一管理，裸指针直接构造易致double-free、内存泄漏或悬空指针。
shared_ptr 初始化必须用 make_shared 或 new？
不能直接用裸指针构造 shared_ptr，否则极易引发 double-free 或悬挂引用。最安全的方式是始终优先用 std::make_shared，它一次分配对象和控制块，效率高且异常安全。
如果必须从已有裸指针转换（比如对接旧代码），只能用 shared_ptr<t>(new T)</t> 形式，但要确保该指针尚未被其他智能指针管理，且不能是栈变量地址——否则运行时崩溃。
-
std::shared_ptr<int> p1 = std::make_shared<int>(42);</int></int>✅ 推荐 -
std::shared_ptr<int> p2(new int(42));</int>⚠️ 可用但不推荐，异常可能泄漏内存 -
int x = 10; std::shared_ptr<int> p3(&x);</int>❌ 崩溃风险极高
shared_ptr 的拷贝和赋值会触发引用计数变化吗？
会，而且这是它的核心机制。每次拷贝、赋值或作为函数参数传值，引用计数自动 +1；超出作用域、重置或析构时 -1。计数归零才真正 delete 所指向对象。
注意：传参时若不需要延长生命周期，应传 const std::shared_ptr<t>&</t> 而非值传递，避免无谓的原子增减操作（尤其在高频调用路径中）。
立即学习“C++免费学习笔记（深入）”；
- 值传递：引用计数先 +1 再 -1，开销可测
- 引用传递：无计数变更，零成本
- 移动赋值：
std::move(p)后原指针变空，计数不减，仅转移所有权
循环引用怎么破？weak_ptr 是万能解药吗？
不是。当两个 shared_ptr 相互持有（如父子节点、观察者模式中的双向绑定），引用计数永不归零，导致内存泄漏。此时需用 std::weak_ptr 打断闭环。
weak_ptr 不增加引用计数，只“观察”对象是否还活着。访问前必须调用 lock() 获得临时 shared_ptr，失败则说明对象已销毁。
- 父类持子类
shared_ptr，子类持父类weak_ptr—— 典型修复模式 -
auto sp = wp.lock(); if (sp) { /* 安全使用 */ }必须判空，wp.lock()返回空shared_ptr表示对象已释放 -
weak_ptr自身不保证线程安全，lock()是原子操作，但后续使用仍需考虑对象生命周期
shared_ptr 和原始指针混用有哪些隐藏雷区？
最危险的是用 shared_ptr 管理某块内存，同时又用裸指针保存其 .get() 结果并长期持有。一旦 shared_ptr 释放，裸指针立刻悬空，而编译器完全不报错。
另一个常见问题是误将 shared_ptr 的 .get() 传给要求“接管内存”的 API（如某些 C 接口带 free 语义），导致重复释放。
- 永远不要长期保存
p.get()的返回值 - 调用 C 函数时，确认它是只读访问还是需要接管内存；若需接管，改用
release()并手动管理（此时已放弃智能指针保护） - 调试时可用
p.use_count()查当前引用数，但别依赖它做逻辑判断（竞态条件下不可靠）
实际项目里，shared_ptr 的误用往往不出现在初始化，而藏在跨模块数据传递、回调捕获、以及和 C 风格 API 交互的边界上。多看一眼 use_count() 和谁在 hold 它，比背规则更管用。
