应查看leak summary中“definitely lost”行的“in x blocks”，该数值即为泄漏内存块数量；其后的字节数（如“100 bytes in 2 blocks”）即为真实泄漏总大小，代表已完全丢失控制权、需优先修复的内存。
直接看 HEAP SUMMARY 和 LEAK SUMMARY 两块，别翻全程日志
怎么看“泄漏次数”（即泄漏的内存块数量）
Valgrind 不说“泄漏次数”，它说“blocks”——也就是未释放的独立内存分配单元数。这个数字出现在 LEAK SUMMARY 的第一行：
-
definitely lost: 100 bytes in 2 blocks→ 表示有 2 次 malloc/calloc/realloc 调用没配对 free，不是“泄漏了 2 次”，而是“当前有 2 块孤立内存” - 如果看到
possibly lost: 40 bytes in 1 block，也计入“块数”，但属于间接/不确定泄漏，比如指针被局部变量临时遮蔽 -
still reachable: 2048 bytes in 4 blocks不算泄漏（程序退出时仍有指针能访问），但块数仍会显示，别误当成泄漏
怎么看“泄漏大小”（即总字节数）
大小分两个层级看，关键在 HEAP SUMMARY 和 LEAK SUMMARY 的对应关系：
-
in use at exit: 100 bytes in 2 blocks（来自HEAP SUMMARY）是总和，含所有未释放块，但不区分类型 -
definitely lost: 100 bytes in 2 blocks（来自LEAK SUMMARY）才是你要盯的“真实泄漏量”——它已排除still reachable等非问题项 - 注意单位：Valgrind 默认用字节（bytes），大数会自动转成 KB/MB，比如
1,048,576 bytes就是 1 MB
为什么 definitely lost 和 in use at exit 数值有时不一致
因为 in use at exit 包含所有“退出时还挂着的堆内存”，而 definitely lost 只统计那些“连指针都找不到了”的内存。常见原因：
- 全局或静态指针持有内存 → 属于
still reachable，不报泄漏，但计入in use at exit - 函数返回前把指针存进某个结构体但没清空 → 可能归为
indirectly lost，大小计入总和但不进definitely - 使用了
--show-leak-kinds=all才能看到全部分类；默认只显示definitely和indirectly
真正要修复的，永远是 definitely lost 行里的字节数和块数——它们对应着明确丢失控制权的内存，且 Valgrind 能准确定位到 malloc 那一行。
