Valgrind 堪称 Linux 环境下诊断内存泄漏的强力工具，但很多开发者在安装环节就遇到阻碍——命令行提示 not found，这通常只是包名选择有误。Debian/Ubuntu 用户只需记住一条：执行 sudo apt install valgrind，不要碰 valgrind-dbg，后者仅包含调试符号，没有可执行程序。CentOS/RHEL 7 使用 yum install valgrind，8 及以上版本必须改用 dnf install valgrind，Arch 则用 pacman -S valgrind。安装完成后立即运行 valgrind --version，看到版本号才算真正装好；如果仍然报错，多半是误装了某个 debuginfo 子包。
装完 valgrind 命令却报 command not found？先查包名对不对
Ubuntu/Debian 系必须运行 sudo apt install valgrind，而不是 valgrind-dbg——后者仅仅是调试符号包，并不包含 valgrind 可执行文件。CentOS/RHEL 7 执行 sudo yum install valgrind，8+ 版本则换成 sudo dnf install valgrind。Arch Linux 用户使用 sudo pacman -S valgrind。安装后立刻验证：valgrind --version 有输出才算成功；若仍报错，请检查是否误装了仅含 debuginfo 的子包。
valgrind 报告全是 ???:???？编译时漏了 -g 或用了 -O2
Valgrind 定位代码行完全依赖二进制文件中的 DWARF 调试信息。编译时未加 -g（例如 gcc -o app app.c），报告里就只剩地址和问号。同时，-O2 及以上优化等级会内联函数、删除临时变量，导致行号错位甚至无法溯源。稳妥的做法是：gcc -g -O0 -o app app.c。CMake 用户请确认 CMAKE_BUILD_TYPE 设为 Debug，否则 -g 可能被忽略。验证符号是否存在：file app 输出应包含 “with debug_info”，nm -C app | grep main 能看到函数名。
跑出的泄漏报告里 definitely lost 是 0，但内存还在涨？程序没正常退出
Valgrind 只在目标进程 clean exit（return 0 或 exit(0)）后才执行最终泄漏扫描。如果程序因为段错误、信号终止或死循环卡住，memcheck 就不会触发完整检查，此时 definitely lost 显示为 0 属于假阴性。请确保测试用例能顺利到达 main 结尾；对于长期运行的服务，可以使用 --tool=memcheck --leak-check=full --show-leak-kinds=all --track-origins=yes 配合 kill -15 优雅终止后再查看报告。另外，fork() 后的子进程 fd 泄漏默认不会被跟踪，需要额外添加 --track-fds=yes。
报告里大量泄漏来自 libc.so.6 或 libstdc++.so？别急着改代码
看到 suppressed: 1234 bytes in 5 blocks 可以直接跳过——这是 Valgrind 内置抑制规则匹配到的已知无害行为。如果泄漏堆栈频繁指向系统库（尤其是 /lib/x86_64-linux-gnu/libc.so.6），大概率是 std::string 缓冲池、glibc malloc arena 延迟释放等机制所致，并非你的代码存在问题。重点盯住你自己源码路径下的 definitely lost 行；still reachable 多数是全局缓存或单例，优先级低于 definitely lost。
真实环境中最容易被绕过的点：Valgrind 不检测栈溢出，也不处理 mmap(MAP_HUGETLB) 分配的内存；它会使程序变慢 20–100 倍，某些依赖时序触发的 bug 在 Valgrind 下反而无法复现。
