shared_ptr循环引用发生于双方相互持有导致引用计数无法归零；weak_ptr通过不增加引用计数并配合lock()安全访问来破环，需在非拥有关系端使用。
shared_ptr 循环引用是怎么发生的
当两个 shared_ptr 相互持有对方管理的对象时，各自的引用计数永远无法降到 0，导致内存泄漏。典型场景是双向链表节点、父子对象关系（如树结构中父节点持子节点的 shared_ptr，子节点又用 shared_ptr 回指父节点）。
根本原因是 shared_ptr 的引用计数只在析构或重置时递减，而双方都“等着对方先释放”，结果谁都不释放。
weak_ptr 如何打破循环
weak_ptr 不增加引用计数，只“观察”目标对象是否还活着。它不能直接访问对象，必须调用 lock() 获得一个临时的 shared_ptr —— 如果原对象已销毁，lock() 返回空 shared_ptr。
实战中，把“非拥有关系”的那一端换成 weak_ptr 即可破环。例如子节点对父节点的引用应为 weak_ptr，而不是 shared_ptr。
- 使用
weak_ptr::lock()获取安全访问：返回shared_ptr，自动处理生命周期检查 - 避免直接用
weak_ptr::operator->()—— 它不存在，强制你显式调用lock() - 不要长期缓存
lock()返回的shared_ptr，除非你明确需要延长对象生命周期
常见误用与陷阱
很多人以为只要用了 weak_ptr 就万事大吉，其实仍有几个关键坑：
- 从裸指针或
shared_ptr.get()构造weak_ptr是未定义行为 —— 必须由同一个shared_ptr初始化 -
weak_ptr本身不保证线程安全：多个线程同时调用lock()没问题，但若一个线程正在析构对象，另一个线程的lock()可能返回空，需业务逻辑容错 - 误用
expired()判断后直接解引用：它只是快照，调用完到实际使用之间对象仍可能被销毁；正确做法是auto sp = wp.lock(); if (sp) { /* use *sp */ } - 在 lambda 捕获中混用
shared_ptr和weak_ptr：若捕获shared_ptr
会导致隐式延长生命周期，应捕获 weak_ptr并在 lambda 内部lock()
会导致隐式延长生命周期，应捕获 一个最小可验证示例
下面代码演示父子类间用 shared_ptr + weak_ptr 避免泄漏：
#include#include struct Child; struct Parent { std::shared_ptr
child; ~Parent() { std::cout << "Parent destroyed\n"; } }; struct Child { std::weak_ptr
parent; // 注意：不是 shared_ptr ~Child() { std::cout << "Child destroyed\n"; } }; int main() { auto p = std::make_shared
(); auto c = std::make_shared (); p->child = c; c->parent = p; // weak_ptr 不增加 p 的引用计数 // 此时 p 的引用计数为 1（main 中的 p），c 的引用计数为 1（p-youjiankuohaophpcnchild） // 函数结束时 p 和 c 都能正常析构}
如果把
std::weak_ptr换成std::shared_ptr，程序退出时两个对象都不会析构 —— 这就是循环引用的真实表现。真正难的不是知道该用
weak_ptr，而是识别出哪些引用是“非拥有”的。这依赖对数据所有权边界的清晰判断，稍一模糊，weak_ptr就会变成掩盖设计缺陷的胶带。
