“definitely lost”表示内存被分配后无任何指针指向且未释放，valgrind可100%确认为泄漏，必须修复；其后栈回溯能精确定位malloc与缺失free的代码行。
直接看“definitely lost”行，它代表必须修复的泄漏；其他类别要结合上下文判断是否真有问题。
“definitely lost”是最关键的泄漏信号
这一类表示：内存被分配后，程序中没有任何指针还指向它，且未调用 free 或 delete。Valgrind 能 100% 确认这是泄漏。
- 典型输出：
==1234== 400 bytes in 1 blocks are definitely lost - 后面紧跟着的栈回溯（
at ... leak.c:5）能准确定位到哪一行malloc没配对free - 即使程序逻辑上“本该释放”，只要运行路径没走到那一步，就归为
definitely lost
“indirectly lost”是连带泄漏，别单独处理
它本身不独立存在，而是因为某个 definitely lost 块里存了指向其他内存的指针，导致那些内存也“失联”了。
- 比如结构体指针
struct node *head = malloc(...)泄漏了，而head->next指向的后续节点也会被标为indirectly lost - 修复源头的
definitely lost后，indirectly lost通常自动消失 - 单独给
indirectly lost加free很可能引发 double-free 或 crash
“possibly lost”和“still reachable”常被误读
这两类不是 bug，但容易让人紧张——得看具体场景才能判断要不要动。
-
possibly lost：指针还在作用域内，但 Valgrind 不确定它是否还能被安全访问（比如只存在栈变量里，没被传出去）。常见于局部指针未置 NULL、或复杂控制流中分支遗漏 -
still reachable：程序退出时，仍有合法指针指向已分配内存（如全局缓存、单例对象、main 函数末尾未 free 的临时 buffer）。多数情况是设计使然，不是错误 - 若在库函数（如
libcurl、glib）初始化后报告still reachable，基本可忽略——它们内部管理自己的长期内存
HEAP SUMMARY 里的数字有陷阱
in use at exit: X bytes in Y blocks 是总和，但不能直接当成“泄漏量”。它把四类混在一起统计，掩盖了真正危险的部分。
- 重点对比：
definitely lost和indirectly lost的字节数之和，才是你必须 fix 的硬泄漏 -
total heap usage: A allocs, B frees中的A - B应该 ≈definitely + indirectly字节数；如果不等，说明有realloc或calloc混用、或某处free被跳过了 - 如果
still reachable占比极大（比如几百 MB），要检查是不是忘了在程序退出前清理大缓存，而不是怀疑工具误报
最易被忽略的一点：Valgrind 不分析静态存储期对象（如 static int buf[1024]）或 mmap 分配的内存，这些不会出现在 LEAK SUMMARY 里。真要查完整生命周期，得配合 Massif 或 /proc/PID/status 手动核对 RSS 增长。
