必须同时加-g和-o0编译，否则valgrind无法定位源码行号而退入stl内联函数；still reachable和possibly lost多为正常raii行为，应重点修复definitely lost和indirectly lost。
为什么Valgrind报告里全是std::vector::_M_realloc_insert这类STL栈帧
因为你没关编译器优化，或者漏了-g，导致Valgrind看不到你自己的代码行号。它不是“报错了STL”，而是根本找不到你的main.cpp:42，只能退到libstdc++.so内部函数里打转——那些_M_allocate、_M_construct全是你调用push_back或resize时被内联展开后残留的痕迹。
怎么让报告回到你的源码行号
必须同时满足两个硬条件：
-
-g：生成调试符号，没有它，所有文件名/行号都是???:??? -
-O0：禁用优化。哪怕只用-O1，std::vector的emplace_back也可能被内联进调用点，栈帧直接消失；-O2以上基本等于放弃定位
验证是否生效：
- 运行
readelf -S ./myapp | grep debug，确认有.debug_*段 - 运行
objdump -t ./myapp | grep main，确认符号表里有你自己的main函数（不是__libc_start_main）
报告里还有still reachable和possibly lost怎么办
别急着改STL用法——这些大概率不是泄漏，而是glibc内存管理机制+RAII生命周期共同作用的结果：
-
still reachable：比如全局std::map、单例缓存、日志队列，进程退出前还活着，属于预期行为 -
possibly lost：常见于std::string临时对象、std::function捕获块、或析构顺序晚于main结束的RAII对象 - 真正要修的是
definitely lost和indirectly lost：前者是new后完全丢失指针，后者是父容器（如std::vector<myclass></myclass>）没清理导致子指针连带泄漏
怀疑是STL容器自身问题？先排除glibc内存碎片假象
进程内存持续上涨但Valgrind不报泄漏？很可能是glibc的malloc没把小块内存还给OS，不是代码写错了：
- 用
pmap -x PID看实际RSS，对比valgrind --tool=massif输出的堆峰值 - 如果
massif峰值稳定但RSS涨不停，基本就是glibc的brk堆管理策略导致的“假泄漏” - 真要治碎片，C++17起可用
std::pmr::synchronized_pool_resource接管分配器，绕过glibc默认堆
Valgrind本身不分析内存是否还给OS，它只管“有没有指针指向这块内存”。所以看到满屏STL，第一反应不该是怀疑库，而是检查编译命令里有没有偷偷带上-O2，或者cmake里CMAKE_BUILD_TYPE=Debug是不是被覆盖了。
