Valgrind能查malloc/new未配对free/delete、use-after-free、buffer overflow、uninitialized value等运行时内存错误，但查不到编译期问题和纯逻辑错误；必须用-g -O0编译，依赖memcheck工具配合--leak-check=full等参数检测，需注意still reachable可忽略，而definitely lost和Invalid read/write需重点处理。
Valgrind能查哪些C++内存问题
Valgrind不是编译器插件，也不是静态分析工具，它通过动态二进制插桩在程序运行时监控内存访问——这意味着它能捕获malloc/new未配对free/delete、使用已释放内存（use-after-free）、越界读写（buffer overflow）、未初始化内存读取（uninitialized value）等真实运行时错误。但它查不到编译期问题（比如类型不匹配），也看不到纯逻辑错误（比如算法错）。最关键的是：必须用-g编译，否则报错位置全是问号。
编译时必须加-g且禁用优化
Valgrind依赖调试符号定位问题行号，没-g就只能显示汇编地址；而-O2或更高优化会让变量被寄存器重用、代码重排，导致报告的“未初始化”或“无效读”位置完全失真。实操中直接用：
g++ -g -O0 -std=c++17 main.cpp -o main。如果项目用CMake，记得在
CMakeLists.txt里设set(CMAKE_BUILD_TYPE Debug)并确认CMAKE_CXX_FLAGS_DEBUG包含-g -O0。有人试过-O1，结果Valgrind报出一堆假阳性——别省这点编译时间。
用memcheck检测核心内存错误
Valgrind默认子工具是memcheck，覆盖绝大多数C++内存问题。启动命令很简单：
valgrind --leak-check=full --show-leak-kinds=all ./main。关键参数说明：
-
--leak-check=full：不只报“有泄漏”，还列出每块泄漏内存的分配栈 -
--show-leak-kinds=all：把definitely lost（确定泄漏）、possibly lost（可能泄漏）、still reachable（全局指针持有）全打出来 -
--track-origins=yes：查Conditional jump or move depends on uninitialised value时必加，否则只告诉你“用了未初始化值”，不告诉你哪一行赋的值 - 如果程序带参数，直接跟在
./main后面，比如./main --input test.dat
常见误报和真实陷阱
Valgrind报告里最让人困惑的是still reachable——这通常不是bug，而是全局容器（比如static std::vector）在main结束前没清空，但进程退出时OS会回收，可忽略。真正要盯紧的是definitely lost和Invalid read/write。另外两个坑：
立即学习“C++免费学习笔记（深入）”；
- 第三方库（如Boost、Qt）可能触发
Conditional jump depends on uninitialised value，但实际是库内部优化所致，加--suppressions=/usr/lib/valgrind/default.supp可过滤 - C++ RAII对象析构顺序引发的use-after-free：比如
std::shared_ptr管理的资源被提前释放，而另一个weak_ptr还在尝试lock()——Valgrind能抓到，但堆栈可能指向weak_ptr::lock而非原始reset()调用点，得顺着引用计数变化反向排查
Valgrind本身不检查线程安全，多线程下的竞争条件要用helgrind或drd，但它们开销更大、误报更多——先用memcheck扫干净单线程内存问题，再考虑并发工具。
