C++标准不支持引用图回收，因其要求对象生命周期在编译期静态分析，而引用图回收依赖运行时遍历对象图，与RAII和确定性析构根本冲突；shared_ptr仅局部计数且无法检测循环引用，需weak_ptr或明确所有权设计来避免泄漏。
为什么 C++ 标准不支持引用图回收
因为 C++ 的对象生命周期必须在编译期可静态分析，而引用图回收（如 Java/Python 的 GC）依赖运行时遍历对象图、识别不可达节点——这与 RAII 和栈对象的确定性析构根本冲突。强行加引用计数或标记清除，会破坏 noexcept 析构、干扰 move 语义，并让 unique_ptr 和 shared_ptr 的行为变得不可预测。
shared_ptr 不能构成引用图，只能做局部计数
shared_ptr 的引用计数只对单个指针实例有效，它不跟踪谁指向了谁。两个 shared_ptr 指向同一对象但彼此不知情，更不会自动检测循环引用。一旦出现循环（比如 A 持有 shared_ptr<B>，B 又持有 shared_ptr<A>），引用计数永不归零，内存就泄漏了。
常见错误现象：~A() 和 ~B() 完全不被调用，Valgrind 报 “still reachable”；调试时发现 use_count() 始终 ≥2。
- 用
weak_ptr打断循环：只在需要临时访问时锁一下，避免长期持有强引用 - 手动设计所有权链：比如让父对象用
unique_ptr管理子对象，子对象用裸指针或weak_ptr回指父对象 - 别把
shared_ptr存进容器再跨模块传递——容易意外延长生命周期
真要模拟引用图回收？得自己建图 + 周期性扫描
这不是标准做法，但有些嵌入式或脚本引擎场景会这么做。核心是：所有对象继承一个基类，注册到全局图中；每个对象记录自己的引用字段（通过模板或宏注入）；GC 线程定期从根集（如全局变量、栈帧）出发 DFS 遍历，标记可达对象，未标记的批量析构。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
代价很高：
- 每个对象多出至少 16–32 字节元数据（图节点 + 引用列表）
- 无法安全析构含
noexcept要求的类型（GC 过程可能抛异常） - 与
malloc/new混用会崩溃——必须统一用自定义分配器 - 多线程下需读写锁，而锁本身又可能被 GC 线程阻塞
示例伪码：
class GCObject { static std::unordered_set<GCObject*> all_objects; void register_self() { all_objects.insert(this); } };
真正该做的：用 RAII + 明确所有权边界
C++ 的“自动生命周期管理”不是靠猜谁还活着，而是靠写清楚谁拥有谁。栈对象最安全；堆对象优先用 unique_ptr；跨作用域共享才考虑 shared_ptr；所有裸指针都默认是观察者，不参与所有权决策。
容易被忽略的一点：shared_ptr 构造时若传入自定义删除器，该删除器必须满足 std::is_nothrow_move_constructible，否则某些容器操作（如 vector::resize）可能异常中止，导致资源泄漏——这个约束连很多资深开发者都会漏掉。
