Valgrind 不适合日常自测，因其启动和运行极慢（5–10倍降速）、仅支持进程级检测、无法对接单元测试或CI高频流程，且需-g -O0编译和动态链接才能输出有效调试信息。
Valgrind 不适合“日常自测”这种高频、轻量的场景——它启动慢、运行慢、输出冗长，强行塞进每次保存就跑的流程里，只会让人关掉它。
为什么 valgrind --leak-check=full 不能当单元测试跑
Memcheck 工具会让程序运行变慢 5–10 倍，且必须等整个进程退出后才汇总泄漏报告。这意味着：
- 你无法在函数级或测试用例级快速反馈，
valgrind只能包裹整个可执行文件，不支持单个main()片段或测试函数 - 若程序带交互（如读 stdin、监听 socket），
valgrind会卡住等待输入，无法自动化 - CI 中每次编译后都跑 full 检查，会显著拖慢流水线；而跳过
--leak-check=full又大概率漏掉间接泄漏 - 它不识别 RAII 或智能指针的语义，对 C++ 程序容易误报“still reachable”，需人工判读
真正可行的日常接入方式：只在关键节点触发
把 valgrind 当成“听诊器”，不是“心电监护仪”。只在以下明确时机手动运行：
- 每次内存密集模块（如 parser、codec、cache layer）完成一轮功能验证后，用
valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all --track-origins=yes ./my_module_test - 本地复现了 crash 或诡异行为时，加
--vgdb-error=0启动 GDB 联调，直接定位非法访问点 - 发布前最后一版集成包，跑一次
valgrind --tool=memcheck --leak-check=full --log-file=valgrind.log ./app --no-daemon -c test.conf，把 log 提交进 MR 附件
编译环节必须做的三件事，否则 valgrind 输出等于废纸
没有这些，valgrind 只能告诉你 “by 0x40052D: main (in ./a.out)”，而不是 “by 0x40052D: parse_json (json.c:47)”：
- 编译必须带
-g：否则无源码行号映射 - 必须禁用优化：
-O0；-O1就可能让变量被优化掉，导致--track-origins=yes失效 - 避免静态链接：
gcc -g -O0 -o app app.c，不要加-static，否则valgrind无法拦截 malloc/free 符号
比 full leak check 更实用的日常检查组合
多数内存问题其实在运行中就能暴露，不必等 exit：
-
valgrind --tool=memcheck --undef-value-errors=yes ./app：立刻捕获未初始化内存参与条件判断（比如if (flag)中flag是栈上未赋值变量） -
valgrind --tool=memcheck --read-var-info=yes ./app：配合-g显示变量名而非仅地址，调试更直观 -
valgrind --tool=memcheck --freelist-vol=10000000 --freelist-big-blocks=1000000 ./app：防止大内存块被提前回收掩盖 use-after-free
真正要警惕的是那些“没报错但行为异常”的情况——比如某个结构体字段偶尔为零、数组越界却没 crash。这些恰恰是 valgrind 最擅长揪出的隐性错误，但需要你主动在怀疑点停下、插桩、重放，而不是指望它自动融入日常节奏。
