在makefile中集成valgrind需定义独立目标（如valgrind: myapp），显式依赖可执行文件，添加--error-exitcode=1确保错误退出码，并注意工作目录与参数传递。
Makefile里加Valgrind要绕开直接执行的坑
Valgrind不是编译器，不能像gcc那样参与编译流程；它是个运行时工具，必须在可执行文件生成后才起作用。所以“放进Makefile一起跑”的本质，是让make在构建完程序后自动用valgrind去跑它——不是插进CC或LD链里，而是新增一个独立的make check或make valgrind目标。
定义valgrind目标时必须显式依赖可执行文件
否则make valgrind可能在程序还没编译完就报错“找不到xxx”，或者静默跳过。关键点是把你的主程序名写成该目标的先决条件：
valgrind: myapp valgrind --leak-check=full --show-leak-kinds=all ./myapp
-
myapp必须是Makefile里已定义的、能被make识别的target（比如由myapp: main.o utils.o生成） - 不要写成
valgrind: ./myapp——路径前缀会让make误判为普通文件而非target - 如果程序需要参数，直接跟在
./myapp后面，比如./myapp test_input.txt
调试阶段建议加--track-origins=yes和--vgdb-error=0
默认的valgrind输出对内存越界或未初始化读的定位很模糊，尤其在优化过的代码里。这两个选项能显著提升诊断效率：
-
--track-origins=yes：告诉Valgrind追踪未初始化值的来源（代价是慢2–3倍，但值得） -
--vgdb-error=0：遇到第一个错误就暂停，并启动GDB监听，方便实时查栈、变量、寄存器 - 别长期开着
--tool=memcheck——它是默认值，显式写出来反而容易漏掉其他工具如helgrind（多线程竞态）
CI或自动化脚本里记得加--error-exitcode=1
Valgrind默认退出码总是0，哪怕检测到严重泄漏或非法访问。这会导致make valgrind || echo "failed"永远不触发失败分支：
valgrind: myapp valgrind --leak-check=full --error-exitcode=1 ./myapp
-
--error-exitcode=1让任何错误（包括definitely lost、invalid read）都返回非零码 - 注意：
--error-exitcode只影响错误类问题，不控制“still reachable”这类警告的退出码 - 若想严格拦截所有泄漏，得配合
--errors-for-leak-kinds=definite,possible再设退出码
./myapp时，当前路径是Makefile所在目录，但程序可能依赖./data/或../config.ini。运行前没切对路径，会误报“文件打开失败”之类的问题，得用cd $(dir $(firstword $(MAKEFILE_LIST))) && ./myapp这类方式兜底。
