valgrind不运行测试用例，而是让测试二进制在它监控下执行；只需用valgrind --tool=memcheck --leak-check=full ./test_runner启动带调试符号的测试程序，注意处理超时、子进程跟踪及ci环境权限等问题。
Valgrind 本身不运行测试用例，它只检测你“实际执行”的程序行为；所以关键不是“配合测试用例”，而是**让测试用例跑在 Valgrind 下**——只要测试路径触发了有问题的内存操作，Memcheck 就能捕获。
怎么把单元测试或集成测试塞进 Valgrind
多数 C/C++ 测试框架（如 CUnit、Google Test、Catch2）最终生成的是可执行文件。你不需要改测试逻辑，只需用 valgrind 启动它：
- 确保测试二进制带调试符号：
gcc -g -O0或cmake -DCMAKE_BUILD_TYPE=Debug - 直接运行：
valgrind --tool=memcheck --leak-check=full ./test_runner - 如果测试需要参数（比如指定测试名），加在最后：
valgrind ... ./test_runner --gtest_filter=MyTest.MemoryLeak - 避免因超时失败：Valgrind 会让程序慢 10–50 倍，记得调大测试框架的 timeout 阈值
为什么单独跑一个 test 函数经常漏问题
Valgrind 检测的是“运行时实际发生的内存操作”，不是静态代码路径。常见漏检场景：
- 某个 test case 没真正调用到分配内存的函数（比如分支没走、early return 了）
- 泄漏发生在
setup()或全局对象构造中，但你只跑了单个 test，没走完整生命周期 - 多线程测试里，
pthread_create启的线程没等结束就退出，Valgrind 来不及扫描其堆栈 - 使用了
fork()：默认不跟踪子进程，得加--trace-children=yes
--leak-check=full 和 --show-leak-kinds=all 的真实影响
这两个选项决定你能看到多少“可疑但未必是 bug”的内存状态：
-
--leak-check=full：必须加，否则只报 summary，不显示哪一行 malloc 没 free -
--show-leak-kinds=all会同时显示四类泄漏：definitely lost（真泄漏）、indirectly lost（被 definitely lost 指针间接引用）、possibly lost（循环引用或栈上指针丢失）、reachable（还有指针能访问，但可能本该释放） - 实践中
possibly lost和reachable最容易误判——比如全局缓存、单例对象生命周期长于 main，它们不是 bug，但会被列出来 - 若只想聚焦高危问题，用
--show-leak-kinds=definite,indirect更干净
CI 中跑 Valgrind 容易卡住的三个点
自动化环境比本地更脆弱，这几个地方不处理好，CI 就会静默失败或假阳性：
- 输出默认写到 stderr，CI 日志可能截断长堆栈；务必加
--log-file=valgrind.log - 某些 CI runner（如 GitHub Actions 默认容器）缺
/proc/sys/vm/max_map_count权限，Valgrind 启动失败；需提前sysctl -w vm.max_map_count=262144 - Valgrind 自身可能被信号中断（如收到 SIGTERM），导致日志不全；建议用
timeout -s SIGQUIT 300s valgrind ...控制最长运行时间
最常被忽略的是：Valgrind 报的 “still reachable” 内存，往往不是泄漏，而是程序设计如此——比如 log buffer、配置缓存、TLS 存储。别一看到非 zero 就 panic，先看它是不是在 main 返回前还持有有效指针。
