最直接信号是对象析构函数完全不执行——哪怕加了std::cout或日志也无输出，说明生命周期被锁死；优先排查parent/children双向shared_ptr、观察者模式反向持有、lambda捕获shared_from_this()后存回调句柄三类高危结构。
怎么一眼看出 shared_ptr 循环引用正在发生
最直接的信号不是内存涨得快，而是对象析构函数完全不执行——哪怕你加了 std::cout 或日志输出，也一条都不打。这说明对象生命周期被锁死，根本没走到析构那步。
排查时优先盯住三类代码结构：
- 树/图节点类里同时存在
parent和children字段，且都用std::shared_ptr - 观察者模式中，被观察者持有观察者的
std::shared_ptr，观察者又反向持有被观察者的std::shared_ptr - 异步回调（尤其是 lambda）里捕获了
shared_from_this()，同时该对象内部又存了回调句柄
这些不是“可能出问题”，而是只要出现，90% 以上概率已形成循环。别等线上报警，代码 review 阶段就该标红。
用 use_count() 和析构日志做最小化验证
use_count() 不是万能诊断工具，但它是最快确认是否卡在非零值的手段。关键不是看它返回几，而是看它在预期释放点之后是否仍 > 0。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 在疑似泄漏对象的析构函数第一行加
std::cout ，确保编译器没优化掉 - 在对象生命周期末尾（比如函数 return 前、作用域结束前）打印
p->use_count()，对比预期值 - 注意：不要在多线程环境直接打印
use_count()，它非原子，仅用于单线程调试路径
如果发现析构没调用，且 use_count() 稳定停在 1 或 2，基本可断定有外部或内部强引用未释放。
weak_ptr 破环不是无脑替换，得看谁该拥有谁
把 std::shared_ptr 换成 std::weak_ptr 本身不解决问题，关键是要明确所有权方向。例如树节点中：children 是子节点的拥有者，必须用 std::shared_ptr；而 parent 是观察关系，应改用 std::weak_ptr。
典型错误写法：
struct TreeNode {
std::shared_ptr<TreeNode> parent; // ❌ 这里不该拥有 parent
std::vector<std::shared_ptr<TreeNode>> children;
};
正确改造：
struct TreeNode {
std::weak_ptr<TreeNode> parent; // ✅ 只观察，不延长生命周期
std::vector<std::shared_ptr<TreeNode>> children;
void do_something_with_parent() {
auto p = parent.lock(); // 安全提升，失败则返回空
if (p) {
// 使用 p
}
}
};
重点：每次访问 weak_ptr 必须先调用 lock()，不能直接解引用；否则可能访问已析构对象。
大规模重构时最容易被忽略的坑
大型项目里，循环引用往往藏在跨模块边界的地方：A 模块导出一个接口，B 模块实现并传回一个 shared_ptr 给 A，而 A 内部又把它存进某个长期存活的对象里——双方都没意识到自己正参与一个隐式环。
这类问题难定位，因为泄漏点和构造点相距甚远。应对策略：
- 禁止在接口层传递裸
std::shared_ptr，改用std::weak_ptr或原始指针 + 明确生命周期注释 - 所有含
shared_from_this()的类，必须在头文件顶部加注释说明“该类实例生命周期由外部强引用保证” - CI 中加入静态检查规则：禁止在类成员中同时出现两个方向的
std::shared_ptr互指（可用 clang-tidy 自定义检查）
最麻烦的不是修复，而是发现——很多循环引用在对象创建后数小时才暴露，靠运行时监控几乎来不及。真正有效的防线，是在设计阶段就拒绝双向强引用建模。
