valgrind对std::shared_ptr循环引用“视而不见”是因为它只检测未释放的内存（definitely lost），而循环引用中对象仍被shared_ptr持有，属still reachable；其析构函数不被调用，但valgrind不检查逻辑析构缺失。
Valgrind 为什么对 std::shared_ptr 循环引用“视而不见”
Valgrind 不会把 std::shared_ptr 循环引用报成 definitely lost，因为它根本没“漏掉”内存——new 出来的对象仍被指针持有，只是永远析构不了。Valgrind 只管“分配后没释放”，不管“该析构却不析构”。所以你看到 still reachable 或干脆无泄漏报告，不等于没问题。
典型表现：
- 程序退出时 Valgrind 报
still reachable: X bytes in Y blocks，且堆栈指向shared_ptr构造或赋值位置 - 对象的
~MyClass()完全没被调用（加日志或断点可验证） - 用
valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all也看不到definitely lost
怎么让 Valgrind 暴露 shared_ptr 循环引用
靠 Valgrind 单独不行，得配合人工干预和辅助手段：
- 在关键类的构造/析构里加
qDebug()或fprintf(stderr, "Ctor/Dtor %p\n", this)，运行时观察是否成对出现 - 用
valgrind --tool=memcheck --track-origins=yes配合shared_ptr::get()使用点，确认原始指针是否意外逃逸（比如传给pthread_create后没回收） - 编译时加
-D_GLIBCXX_DEBUG（GCC），触发 libstdc++ 的调试模式，部分循环引用场景会在运行时报__shared_ptr_access断言失败 - 对疑似对象手动打点：在构造时
std::cout ，在析构前加 <code>std::cout
QSharedPointer / QWeakPointer 怎么用 Valgrind 验证没翻车
Qt 的 QSharedPointer 行为类似 std::shared_ptr，同样怕循环引用；但 QWeakPointer 是解药。Valgrind 能帮你确认它真起作用：
- 把强引用改成
QWeakPointer后，Valgrind 报告的still reachable应明显减少，且对应对象的析构日志必须出现 - 错误写法：
QSharedPointer<a> a(new A); a->b = QSharedPointer<b>(new B); b->a = a;</b></a>→ Valgrind 看不到泄漏，但对象卡住 - 正确写法：
b->a = QWeakPointer<a>(a);</a>→a释放后b->a.isNull()为 true，且 Valgrind 显示该块内存最终被definitely lost以外的方式回收（即正常析构） - 注意：
QPointer只对QObject有效，且只监控对象销毁，不参与引用计数——Valgrind 对它基本无感，别指望它报错
Valgrind 报 “possibly lost” 但代码全是智能指针？先查这三处
possibly lost 常是假阳性，但在智能指针场景下，往往暴露真实问题：
- 裸指针从
shared_ptr::get()拿出后，被存进 C 风格容器（如std::vector<void></void>）或全局 map，导致智能指针“以为任务完成”，但原始指针还在别处活着 - 多线程环境下，
shared_ptr赋值未加锁，引发引用计数竞争，计数异常导致提前释放或永不释放——Valgrind 可能报Invalid read或possibly lost - 静态生命周期对象（如全局
shared_ptr）在main()退出后才析构，而 Valgrind 在main返回后立即快照，把它标为still reachable——这不是 bug，但容易掩盖真正的循环引用
真正难缠的是“析构函数里又 new 了东西但没配对 delete”，这种 Valgrind 会老老实实报 definitely lost，跟智能指针无关，但常被误认为是智能指针的问题。
