std::shared_ptr循环引用会导致内存泄漏，因互相持有使引用计数无法归零；须用std::weak_ptr打破循环，至少一端不参与所有权管理，并通过lock()安全访问。
std::shared_ptr 循环引用会导致内存泄漏
用 std::shared_ptr 管理对象时，如果两个对象互相持有对方的 std::shared_ptr，引用计数永远不会降为 0，对象就永远不析构——这不是 bug，是设计使然。典型场景比如双向链表节点、父子对象关系（如树节点中 parent 和 children 都用 std::shared_ptr）。
常见错误现象：~MyClass() 从不被调用；Valgrind 报告“still reachable”内存；程序退出前 RSS 持续上涨。
- 根本原因是：循环中每个
std::shared_ptr都在增加对方的引用计数，形成闭环 - 不能靠“手动 reset”解决——除非你能精确控制释放顺序，而这在复杂对象图中几乎不可靠
-
std::weak_ptr不参与引用计数，只提供临时访问能力，是破环的唯一标准手段
用 std::weak_ptr 打断单向引用链
原则很简单：在循环中，**至少有一端必须用 std::weak_ptr**，且该端不参与所有权管理。比如父子关系中，子节点用 std::shared_ptr 持有父节点（可选），但父节点必须用 std::weak_ptr 持有子节点（或反之）；双向链表中，prev 指针用 std::weak_ptr，next 用 std::shared_ptr。
关键操作不是“存”，而是“取”：访问前必须调用 lock() 转成临时 std::shared_ptr，检查是否仍有效：
立即学习“C++免费学习笔记（深入）”；
std::weak_ptr<Node> prev_;
// ...
if (auto p = prev_.lock()) {
// p 是有效的 shared_ptr，可安全使用
p->do_something();
} else {
// 原对象已销毁，prev_ 已失效
}
-
lock()返回空std::shared_ptr表示目标已被释放，不是异常情况，必须检查 - 不要长期保存
lock()的返回值——它只是临时延长生命周期，不该替代原始std::weak_ptr - 不能对
std::weak_ptr直接解引用（*wptr或wptr->）——编译不过
shared_ptr 构造 weak_ptr 的时机很关键
std::weak_ptr 必须从已存在的 std::shared_ptr 构造，不能凭空创建或从裸指针构造。这意味着：你不能在对象构造函数里就初始化指向自己的 std::weak_ptr 成员——此时 this 还没被任何 std::shared_ptr 管理。
- 正确做法：用
std::enable_shared_from_this<T>，并在对象已被std::shared_ptr管理后，调用shared_from_this()获取合法std::shared_ptr，再转成std::weak_ptr - 错误写法：
weak_ptr_ = std::weak_ptr<MyClass>(this)—— 这会引发未定义行为 - 如果类继承了
std::enable_shared_from_this<T>，但首次创建对象时没用std::make_shared<T>()（而是new T+ 手动构造std::shared_ptr），shared_from_this()会抛std::bad_weak_ptr
循环引用不一定只发生在两个对象之间
三个及以上对象形成的引用环同样危险，比如 A→B→C→A，或者闭包捕获导致的隐式循环：lambda 捕获 std::shared_ptr<this>，而该 std::shared_ptr 又被成员变量（如回调队列）持有。
- 工具辅助：Clang 的
-Wlifetime（配合-std=c++20）能静态发现部分弱引用误用；AddressSanitizer + LeakSanitizer 可定位泄漏源头 - 调试技巧：在类析构函数打日志，配合
std::shared_ptr::use_count()输出当前计数，快速判断是否卡在循环里 - 真正难的是识别“隐式循环”——比如信号槽机制中，sender 持有 receiver 的
std::shared_ptr，receiver 的槽函数又捕获了 sender 的std::shared_ptr
破环本身不难，难的是在设计阶段就意识到谁该拥有谁、谁只是观察者。一旦引入 std::shared_ptr，就得同步画出所有权图——人脑容易忽略间接引用，机器不会。
