默认 --leak-check=full 仅报告 definitely 和 indirectly lost，需显式加 --show-leak-kinds=all 才显示 possibly lost 与 still reachable；still reachable 非错误但需按场景判断，possibly lost 多因指针偏移或释放不匹配导致。
valgrind --leak-check=full 为什么只报 definitely lost？
默认启用 --leak-check=full 时，Valgrind 实际上只显示 definitely lost 和 indirectly lost，而不会输出 possibly lost 或 still reachable。这不是 bug，是设计行为：它把后两者归为“非严重泄漏”，需显式开启才展示。
常见错误现象是跑完命令发现漏掉某些疑似泄漏的内存块，尤其在 C++ 容器或全局缓存场景下——那些被指针间接持有、或生命周期贯穿程序始终的堆内存，容易被默认过滤。
-
--show-leak-kinds=all才能强制显示全部四类：definitely、indirectly、possibly、still reachable - 单独用
--show-leak-kinds=possible可只看可能泄漏（比如指针偏移进内存块内部） -
--show-leak-kinds=reachable单独看 still reachable，常用于确认日志缓冲区、单例对象等是否属于预期行为
still reachable 算不算泄漏？要看场景
still reachable 表示：程序退出时仍有有效指针指向该内存块头部，只是没主动释放。它不违反内存安全，但可能是资源管理疏忽。
典型使用场景包括：
- 全局
std::vector或static std::string在 main 返回后仍持有堆内存 - 日志模块的预分配缓冲区，设计上就留到进程结束
- C++ 标准库内部缓存（如
std::regex的编译结果），无法由用户控制释放时机
性能/兼容性影响：这类内存不会增长（不随循环调用累积），也不会导致 OOM，但若数量级异常大（比如百万级 still reachable 块），说明存在未清理的长期持有逻辑，应检查构造/析构配对。
possibly lost 的根本原因是 pointer arithmetic
possibly lost 几乎总是因为指针没有指向分配块起始地址，而是算偏了。比如：
char *p = (char*)malloc(100); char *q = p + 10; // q 不再指向块头 free(q); // 错！Valgrind 记录为 possibly lost
或者更隐蔽的情况：
- C++ 中
new[]分配数组，但用delete（非delete[]）释放 → Valgrind 无法匹配分配/释放签名，标记为 possibly lost - 结构体内嵌指针被赋值为
member_ptr = &obj.field，后续又把&obj地址丢了，只剩 field 偏移量 - 手动内存池管理中，从大块里切小块并返回偏移地址，但没保留原始 base 指针
这类问题往往编译期不报错，运行也正常，但 Valgrind 会精准捕获——因为它只认“分配时的起始地址”作为合法释放入口。
如何快速区分 indirect lost 是真问题还是连锁反应？
indirectly lost 本身不是独立泄漏，而是某个 definitely lost 块里存了其他内存块的指针。所以它永远伴随 definitely lost 出现，且调用栈深度更深。
判断逻辑很简单：
- 先定位最顶层的
definitely lost块（看 call stack 最浅层的malloc/new） - 检查该块内容：用
valgrind --track-origins=yes配合--leak-check=full，可看到 “block was alloc'd at…” 后还附带 “and points to …” 的溯源 - 如果那个 definitely lost 块本该是容器（如
std::map内部节点），而它持有的子块也是动态分配的，那整个链路都得修复；否则只是“果”，修根即可
容易踩的坑：直接去改间接块的释放逻辑，却忽略父块早已失控——结果修了十处，泄漏还在，因为源头没堵住。
