加-g且-o0编译才能让valgrind精准定位错误行号；-g缺失导致显示???或汇编地址，-o2优化会干扰错误位置映射；still reachable非bug，definitely lost、invalid read/write和条件依赖未初始化值才是关键问题。
不加-g时Valgrind只能显示问号或汇编地址
Valgrind本身不解析源码，它靠二进制中嵌入的调试符号（DWARF）把内存错误映射回main.cpp:42这种位置。没-g，这些符号就不存在，报告里全是???或0x4012AB这类地址——你得手动反汇编、查调用栈，效率极低。
加-g后错误定位精确到行号，但必须配合-O0
光有-g不够，如果同时开了-O2，编译器会把变量塞进寄存器、合并/删减代码块，导致Valgrind报告的“未初始化值来源”或“越界读位置”指向完全无关的行。实操建议：
- 用
g++ -g -O0 -o app main.cpp编译，不是-O1或-Og，必须是-O0 - CMake用户检查
CMAKE_BUILD_TYPE是否为Debug，并确认CMAKE_CXX_FLAGS里显式含-g -O0 - 运行时加
--track-origins=yes，才能让Use of uninitialised value错误带出变量首次赋值点
常见误判：still reachable不是bug，definitely lost才是真泄漏
Valgrind报告里still reachable常被当成泄漏，其实只是程序退出前还持有指针（比如全局缓存），只要逻辑合理就可忽略。真正要处理的是：
-
definitely lost：malloc/new分配后彻底丢失指针，无法释放 -
Invalid read/write：访问free后的内存、数组末尾多读1字节等 -
Conditional jump or move depends on uninitialised value：分支判断用了未初始化变量，行为不可预测
实际跑一次就能验证-g是否生效
编译后执行valgrind --leak-check=full ./app，看输出里错误行是否带文件名和行号。如果看到类似at 0x401234: foo(int*) (main.cpp:27)，说明-g成功；若只有in ???:0或一堆十六进制地址，立刻重编译，别往下查。
容易被忽略的一点：静态库或第三方依赖如果没带-g，它们内部的泄漏或越界操作可能只显示in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30，这种没法精确定位，只能聚焦自己代码的-g编译。
