循环引用发生在两个shared_ptr相互持有对方对象时，导致引用计数无法归零、内存泄漏；典型场景包括双向链表、父子节点、观察者模式；需用weak_ptr打破循环，其不增加引用计数，访问前必须lock()检查。
循环引用在 shared_ptr 里是怎么发生的
当两个 shared_ptr 相互持有对方所管理的对象时，引用计数永远无法归零，对象就不会析构——这就是循环引用。它不是语法错误，编译运行都正常，但内存悄悄泄漏。
典型场景是双向链表节点、父子对象（比如树节点中父指针和子指针都用 shared_ptr）、观察者模式里观察者和被观察者互相持有时。
- 只要存在 A → B 和 B → A 的
shared_ptr持有链，就构成循环 -
shared_ptr析构时只减引用计数，不检查“谁还指着我”，所以破不了环 - 用
valgrind或 ASan 可能发现内存未释放，但调试器看不出问题
weak_ptr 不是“弱共享”，而是“不参与计数的观察者”
weak_ptr 本身不增加引用计数，它只是对某个 shared_ptr 所管对象的“临时快照”。你不能直接通过 weak_ptr 访问对象，必须先调用 lock() 获得一个临时 shared_ptr —— 如果原对象已销毁，lock() 返回空 shared_ptr。
- 把循环中“非拥有关系”的那一端换成
weak_ptr，比如子节点存父节点用weak_ptr，父节点存子节点用shared_ptr -
weak_ptr构造只能来自同源shared_ptr（或另一个weak_ptr），不能直接从裸指针构造 - 访问前必须检查：
if (auto p = parent.lock()) { /* 安全使用 p */ }，否则可能解引用空指针
常见误用：把 weak_ptr 当成“自动安全的 shared_ptr”
很多人以为只要用了 weak_ptr 就不会出问题，结果在多线程或对象生命周期边界处 crash。根本原因是：它不延长对象寿命，也不保证对象一定活着。
立即学习“C++免费学习笔记（深入）”；
-
weak_ptr::lock()是原子操作，但返回的shared_ptr只保证“那一刻”有效；之后对象仍可能被其他线程释放 - 跨函数传
weak_ptr后再lock()，比在同一个作用域内连续调用更危险 - 在 Lambda 捕获中写
[self = weak_from_this()]() { if (auto p = self.lock()) {...} }是标准做法；但若漏掉lock()检查，直接用self.get()就是未定义行为
用 make_shared 初始化 weak_ptr 的陷阱
weak_ptr 不能直接由 make_shared 创建，它必须绑定到已存在的 shared_ptr。有人试图这样写：weak_ptr<int> w = make_shared<int>(42);</int></int> —— 这会触发隐式转换，但代价是额外一次引用计数增减，且掩盖了所有权意图。
- 正确方式始终是：先有
shared_ptr，再用其构造weak_ptr，例如auto sp = make_shared<int>(42); weak_ptr<int> wp(sp);</int></int> - 如果类想支持
weak_from_this()，必须继承enable_shared_from_this<t></t>，且只能在对象已被shared_ptr管理后调用（即不能在构造函数里调） - 注意
enable_shared_from_this::weak_from_this()返回的是weak_ptr，不是shared_ptr；它的生命周期依赖于首个shared_ptr是否还存在
循环引用真正的难点不在怎么加 weak_ptr，而在于判断哪一端“不该拥有所有权”。这个设计决策一旦定错，后面所有 lock() 检查都只是补救，而不是根治。