shared_ptr循环引用会导致内存泄漏，因引用计数无法归零；weak_ptr是唯一标准解法，不增计数、需lock()转shared_ptr安全访问，不可用裸指针替代。
shared_ptr 循环引用会导致内存泄漏
当两个 shared_ptr 相互持有对方管理的对象时，引用计数永远无法归零，对象不会被析构——这不是“延迟释放”，是彻底不释放。典型场景是父子类双向关联、观察者模式中回调绑定自身、图结构节点互相保存邻居指针等。
关键判断点：只要两个对象通过 shared_ptr 彼此可达，且没有外部强引用维持，就已构成循环引用风险。编译器和静态分析工具（如 clang++ -fsanitize=leak）通常不报错，运行时也无异常，只有 valgrind 或 ASan 检测到内存未释放才能暴露问题。
weak_ptr 是打破循环的唯一标准解法
weak_ptr 不增加引用计数，只“观察”目标对象是否还活着。它不能直接访问对象，必须先调用 lock() 转成 shared_ptr 才能安全使用；若对象已被销毁，lock() 返回空 shared_ptr。
常见用法：
立即学习“C++免费学习笔记（深入）”；
- 父类持子类的
shared_ptr（强引用），子类持父类的weak_ptr（弱观察） - 回调函数中捕获
this时，改用weak_ptr<Self>捕获，调用前if (auto p = ptr.lock()) { ... } - 缓存或监听列表中存储
weak_ptr，遍历时跳过已失效项
注意：weak_ptr 本身不保证线程安全——多个线程同时调用 lock() 是安全的，但 lock() + 使用中间不能跨线程共享该 shared_ptr，否则仍需额外同步。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
不要用 raw pointer 或 this 指针替代 weak_ptr
裸指针（T*）或 this 在对象析构后变成悬垂指针，解引用即未定义行为（UB），比内存泄漏更危险。有人试图在析构函数里手动清空反向指针，但无法覆盖所有路径（比如异常中途退出、多继承析构顺序不确定）。
正确做法是让生命周期关系显式编码在智能指针语义里：谁拥有谁，谁只是临时观察谁。weak_ptr 就是 C++ 标准库为这个语义提供的唯一可信赖机制。
一个易忽略的坑：weak_ptr 构造开销略高于 shared_ptr（内部需访问控制块），但远小于一次堆分配；若频繁调用 lock() 后又立即放弃使用，应考虑是否设计上本就不该持有该引用。
调试循环引用：用 _use_count() 和自定义 deleter 验证
Release 模式下无法直接看引用计数，但调试时可在关键对象的构造/析构中加日志，或在 shared_ptr 构造时传入自定义 deleter：
auto deleter = [](MyClass* p) {
std::cout << "deleting MyClass at " << p << "\n";
delete p;
};
std::shared_ptr<MyClass> ptr(new MyClass, deleter);配合 ptr.use_count()（注意：非线程安全，仅调试用）观察计数变化。若发现某对象的 use_count() 始终 ≥2 且无人再创建新 shared_ptr，大概率存在循环。
真正棘手的是跨模块或模板实例化导致的隐式循环——比如 std::function<void()> 捕获了 shared_ptr，而该 function 又被另一个对象长期持有。这种链路必须靠人工梳理所有权图，weak_ptr 是唯一可控出口。
