必须用 g++ -g -o0 编译并确保程序正常退出，valgrind 才能准确报告内存泄漏；需配合 --leak-check=full --show-leak-kinds=all --track-origins=yes 等选项，并注意 raii 和第三方库干扰。
编译时必须加 -g 且禁用优化
Valgrind Memcheck 依赖调试信息定位问题行号，不加 -g 会导致报告只显示 ???；而 -O2 或更高优化等级会触发变量提升、内存复用等行为，掩盖未初始化读取，甚至让泄漏路径无法追踪。
正确做法是：用 g++ -g -O0 编译（-O0 是默认值，但显式写出更稳妥），避免 -flto、-fomit-frame-pointer 等干扰调试信息的选项。
运行前确认程序能正常退出，不要用 Ctrl+C 中断
Valgrind 只在程序正常结束（即 main() 返回或调用 exit()）时才汇总并打印内存泄漏报告。如果进程被信号终止（比如你按了 Ctrl+C），Memcheck 不会做最终扫描，泄漏会被漏报。
常见陷阱：
- 后台线程未 join 就 return —— 主线程退出后子线程还在跑，Valgrind 认为程序“没结束”，不报告
- 程序卡在阻塞 IO（如
read()等待输入）—— 看似卡住，实则是没到退出点 - 使用
abort()或收到SIGSEGV—— 进程异常终止，Memcheck 来不及收尾
建议加个简单超时逻辑或用 valgrind --tool=memcheck --time-limit=30 控制最长运行时间。
valgrind --leak-check=full --show-leak-kinds=all 是基础组合
默认的 --leak-check=summary 只告诉你“有 3 个块没释放”，毫无价值；--leak-check=full 才会打出每一块的分配栈，配合 -g 编译就能准确定位到 new 或 malloc 那一行。
而 --show-leak-kinds=all 包含 definitely lost（真正泄漏）、possibly lost（可能泄漏，比如指针被压入容器但未取回）、still reachable（全局/静态指针持有，通常不算 bug，但得人工确认）和 suppressed（被 suppress 文件过滤掉的）—— 少一个就可能漏掉关键线索。
完整常用命令示例：
valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all --track-origins=yes ./my_program
--track-origins=yes 对未初始化读取至关重要，它会让 Valgrind 追溯到变量最初未初始化的位置（比如某个 int x; 声明后直接用了），否则只报“use of uninitialised value”却找不到源头。
注意 C++ RAII 和第三方库的干扰
Valgrind 不理解 C++ 析构语义，它只看 malloc/new 分配是否被 free/delete 匹配。所以以下情况容易误报：
-
std::string、std::vector在栈上创建，内部堆内存由析构函数释放 —— Valgrind 能识别标准库的 malloc/free 配对（前提是用系统 malloc，不是 jemalloc 等替代品） - 你自己写的 RAII 类，析构里没显式
delete或free—— Valgrind 会把它当泄漏 - 用了
libcurl、OpenSSL等库，它们内部缓存或全局初始化分配的内存常被标为still reachable，需用--gen-suppressions=all生成 suppress 文件过滤，否则日志刷屏
验证是否真泄漏：先用 --suppressions=valgrind.supp（标准 suppress 文件）跑一遍，再比对剩余报告；对 still reachable，检查是否为 main() 退出前本该存在的全局对象（比如单例），而非你忘了 delete 的堆对象。
最易被忽略的是：Valgrind 本身很慢（5–10 倍），且不能检测栈溢出、越界写入（那是 AddressSanitizer 的事），别指望它覆盖所有内存问题。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
