valgrind 默认输出冗杂，需通过重定向日志、grep筛选关键错误（如“definitely lost”“invalid write”）、组合--quiet与--verbose突出错误、生成抑制规则屏蔽第三方库误报，并人工分析调用栈定位真实内存问题。
Valgrind 默认输出太杂，关键信息被淹没，必须手动筛选。它默认把所有插桩日志、工具元信息、堆栈帧全打出来，真正有用的泄漏点或非法访问反而藏在几百行里。想快速定位问题，得从输出源头控制粒度。
用 --log-file 把输出导出到文件再 grep
终端滚动太快，valgrind 的输出又没分页，直接看容易漏。最稳妥的做法是先落地：
-
valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all ./myapp 2> valgrind.log（注意重定向2>，因为 Valgrind 错误输出走 stderr） - 然后
grep -A5 -B5 "definitely lost" valgrind.log或grep "Invalid write" valgrind.log - 对疑似泄漏点，用
grep -n "at " valgrind.log | head -20快速跳转到调用栈行号
加 --quiet 和 --verbose 组合压制噪音
--quiet 不是“静音”，而是关掉工具初始化那几行版权和版本提示；--verbose 反而会打开更细的内部状态——但两者一起用，能过滤掉中间冗余的“==PID==”前缀行，让错误本身更突出：
valgrind --quiet --tool=memcheck --leak-check=full ./myapp 2>&1 | grep -E "(definitely|invalid|uninitialised|Address.*is)"- 注意：
--quiet会同时压制HEAP SUMMARY，所以不能单独依赖它，必须配合grep提取关键模式
用 --gen-suppressions=all 暂时屏蔽已知误报
有些第三方库（比如 glibc 的 pthread 初始化、Qt 的静态对象）会在启动阶段分配内存但不释放，Valgrind 会报成 “still reachable”，干扰判断。这时别删代码，用抑制规则隔离：
- 先跑一次：
valgrind --tool=memcheck --gen-suppressions=all ./myapp 2> suppress.supp - 编辑
suppress.supp，删掉你确认无害的块（比如含libpthread或libstdc++的段） - 下次检测加参数：
--suppressions=suppress.supp，剩下的就是真问题
真正难的不是生成报告，而是区分哪些 still reachable 是设计如此、哪些是忘了 free。Valgrind 不会替你做这个判断，它只负责把每一块内存的生命周期摊开给你看——你得盯着 by 后面那一串函数调用，看最后一级是不是你的源码文件名和行号。
