valgrind不能直接识别智能指针泄漏，它仅检测底层内存分配未释放（如new未配对delete），不解析c++语义；循环引用导致的definitely/indirectly lost需结合调用栈与代码逻辑反推。
Valgrind 能不能直接看出智能指针泄漏
不能。Valgrind 不解析 C++ 语义，它只看到 malloc、new 的调用和未配对的 free/delete。即使你用了 std::shared_ptr，只要底层内存没被释放（比如循环引用导致引用计数卡在 1），Valgrind 就会报告 definitely lost 或 indirectly lost——但它不会告诉你“这是 shared_ptr 循环引用造成的”。你得结合调用栈和代码逻辑反推。
valgrind --leak-check=full 报 “indirectly lost” 怎么定位源头
这种泄漏往往藏在对象图深处：A 持有 B 的 shared_ptr，B 又持有 A 的 shared_ptr，两者都活着，但没人能触发析构。Valgrind 输出里会显示分配点（比如 new 行），但不会显示谁还拿着指针。
- 先确认是否真有循环引用：在疑似类中检查是否有
std::shared_ptr<thisclass></thisclass>成员或参数传入自身 - 把
shared_ptr换成std::weak_ptr断开强引用链，再跑一次 Valgrind —— 如果indirectly lost消失，基本就是它 - 注意 Qt 场景：
QPointer是弱引用，但不管理内存；如果混用QPointer和shared_ptr指向同一对象，可能掩盖真正的所有权归属问题
为什么加了 -g -O0 还看不到 new 行号，或者行号跳到模板内部
常见原因不是编译选项错，而是智能指针的 make_shared 或构造函数内联展开后，Valgrind 把分配归到了 STL 实现里（比如 __shared_count::__shared_count）。这时候要倒着查：
- 看报错栈最靠近你代码的那一层，比如
MyWidget::init() (widget.cpp:87)，哪怕下一行是 STL，87 行大概率就是创建shared_ptr的地方 - 避免
make_shared干扰：临时改用shared_ptr{new T}，让分配点明确落在你的代码行 - 如果用了自定义删除器（比如文件句柄、GPU 内存），Valgrind 不会管它是否执行——得靠
lsof或 GPU 工具补查，它只盯堆内存
ASan 比 Valgrind 更适合查智能指针泄漏吗
是的，尤其在 macOS Catalina+ 或 CI 环境。ASan 的 detect_leaks=1 能关联分配点与持有者，对循环引用更敏感。但它也有坑：
- 必须所有链接目标（包括静态库）都用
-fsanitize=address编译，否则泄漏发生在非 ASan 模块里就漏检 - Windows 上 MSVC 的 ASan 对 STL 智能指针支持不稳定，建议优先用 Clang-CL
- ASan 报告里如果出现
allocated by thread T0 here:后紧跟着shared_ptr::shared_ptr构造函数，那几乎可以断定是循环引用，不用再猜
真正容易被忽略的是：智能指针本身不泄漏，但它们持有的资源（如 std::shared_ptr<file></file> 配自定义 fclose 删除器）一旦删除器没生效，Valgrind 和 ASan 都只报“内存没释放”，而你得自己意识到 FILE* 是系统资源，不是堆内存。
