断点不生效90%是因为编译未加-g：vscode调试器依赖二进制中嵌入的调试符号，无-g则生成“黑盒”，导致断点变灰、变量显示、单步错行；tasks.json中args必须显式含"-g"，cmake项目需设cmake_build_type为debug并禁用优化。
断点不生效，90%是因为编译时没加 -g，不是 VSCode 有问题，是它根本没生成调试信息。
tasks.json 里漏掉 -g 就等于没调试能力
VSCode 的调试器（gdb 或 lldb）只能读取可执行文件里嵌入的调试符号。没有 -g，编译出来的二进制就是“黑盒”，断点变灰、变量值显示 <optimized out></optimized>、单步跳转错行全是必然结果。
-
args数组中必须显式包含"-g"，位置无关，但不能漏 - 别信“默认开启”——
g++默认完全不生成调试信息 - 多文件项目别用单文件
tasks.json硬凑，-g得作用在所有源文件上，否则部分函数仍无调试符号 - Windows 下 MinGW 用户注意：
args里加了-static-libgcc -static-libstdc++可能导致链接器误判为 GUI 程序，报undefined reference to `WinMain'，此时-g也救不了
launch.json 的 program 路径必须和 tasks.json 的输出严格一致
即使加了 -g，如果 launch.json 找不到那个带调试信息的文件，照样断点失效。常见错配：
-
tasks.json用了"-o", "${fileDirname}/${fileBasenameNoExtension}"，但launch.json的"program"写成"${workspaceFolder}/a.out"—— 它在找默认名，你却输出了自定义名 - Linux/macOS 下路径区分大小写，
${fileDirname}和实际目录名大小写不一致会导致找不到文件 - Windows 用户没设
"externalConsole": true，控制台一闪而过，看似“没运行”，其实是程序退出太快，断点根本没机会触发
CMake 项目里 -g 不是加在 args 里，而是靠构建类型控制
用 CMake 的项目，tasks.json 通常只调 cmake --build，-g 要落在 CMake 配置里，否则 cmake 生成的 Makefile/Ninja 文件本身就不带调试标志。
- 必须设置
set(CMAKE_BUILD_TYPE Debug)，仅靠命令行传-DCMAKE_BUILD_TYPE=Debug不够稳定 - 显式追加调试标志：
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -g3 -O0")——-g3比-g多出宏定义信息，-O0禁用优化，防止内联、重排打乱断点映射 - 如果 CMakeLists.txt 里有
add_compile_options(-O2)这类全局优化，会覆盖Debug模式，必须检查是否被意外启用
最常被忽略的一点：c_cpp_properties.json 里的 compilerPath 和 tasks.json 实际调用的编译器，可以是两个不同版本。IntelliSense 提示看着正常，但 tasks.json 调的却是另一个没装 gdb 支持或头文件不全的 g++，这时 -g 虽然加了，生成的调试信息也可能不完整或不可读。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
