必须重新运行valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes验证，仅改代码不重测等于未修复；该命令覆盖四类泄漏并精确定位初始化问题，且需确保执行真实路径、清理旧二进制、处理非malloc内存与多线程场景。
重新运行 valgrind --leak-check=full 是唯一有效验证方式
改完代码后不 rerun Valgrind，就等于没验证。Valgrind 的检测结果是运行时快照，不是静态分析，不执行就看不到变化。尤其要注意：修复一个 malloc 漏洞后，可能因逻辑调整引入新的 realloc 或 calloc 分配未释放，必须重新走完整流程。
--leak-check=full 和 --show-leak-kinds=all 要一起用
只加 --leak-check=full 会漏掉 still reachable 类泄漏（比如全局指针指向的堆内存）。实际验证时应至少带上：
valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes ./your_program
-
--show-leak-kinds=all强制报告definitely lost、indirectly lost、possibly lost、still reachable四类 -
--track-origins=yes对Use of uninitialised value类问题定位更准，避免修了 A 却漏了 B - 别省略
--track-origins—— 它带来的开销在验证阶段可接受，且能暴露初始化链路上的深层问题
看到 no leaks are possible 不代表万事大吉
这行输出只说明 Memcheck 没发现「确定性」泄漏，但以下情况仍可能出问题：
- 程序提前
exit(0)或被信号终止，导致后续分配未走到释放逻辑 —— Valgrind 不会报泄漏，但业务上就是资源没清理 - 使用了
mmap/MAP_ANONYMOUS等非malloc系统调用分配的内存，memcheck默认不追踪 - 多线程环境下，某个线程崩溃导致其私有堆未释放，Valgrind 可能归为
still reachable而忽略 - 修复时把
free(ptr)改成delete ptr（或反之），类型不匹配会导致未定义行为，Valgrind 可能不报错但程序已不稳定
验证必须覆盖真实执行路径
写个空 main 跑 Valgrind 没意义。要验证就得让程序走到你修复的那块逻辑里：
- 如果泄漏发生在配置加载阶段，确保测试时传入真实配置文件或环境变量
- 如果只在错误分支触发（比如
if (err) { malloc(); return; }），得构造对应错误条件，不能只测 happy path - 对守护进程或服务类程序，用
--log-file=valgrind-out.txt+ 信号触发退出（如kill -TERM $(pidof your_service)），再检查日志中 exit 时的 heap summary
最容易被忽略的是：修复后没清掉旧的 .o 或 a.out，链接的还是老二进制。每次验证前，先 make clean && make 或手动删掉可执行文件再编译。
