VSCode调试C/C++需先打开文件夹再生成launch.json，program必须指向已编译二进制，编译须加-g -O0，注意调试器路径、sourceFileMap映射及避免OneDrive等干扰路径。
找不到 launch.json 或调试配置不生效
VSCode 调试 C/C++ 的核心是 launch.json，但它不会自动生成——必须先打开一个文件夹（而非单个文件），再通过命令面板（Ctrl+Shift+P）运行 Debug: Open launch.json 才会触发向导。如果直接点“运行和调试”侧边栏里的“创建 launch.json”，却没看到 C/C++ 选项，大概率是因为没装 C/C++ 扩展，或当前工作区根目录下没有 tasks.json 或可识别的构建产物。
- 确保已安装官方
C/C++扩展（作者 Microsoft），且未被禁用 - 项目根目录下最好有
build/或out/这类输出目录，否则 VSCode 可能无法推断可执行文件路径 -
launch.json中的program字段必须指向**已编译好的二进制文件**，不是.c或.cpp源码——很多人填"./main.cpp"导致启动失败 - 若用
gdb或lldb，确认系统 PATH 中能直接调用，比如在终端执行gdb --version不报错
breakpoint ignored because generated code not found
这是 Windows + MinGW/MSVC 下高频错误，本质是调试信息缺失或路径映射错乱。VSCode 启动调试器时，会按源码路径去匹配符号表里的文件位置；如果编译时用了相对路径、或项目在 OneDrive/WSL 路径下，就容易对不上。
- 编译时务必加调试标志：
gcc -g -O0 main.c -o main（-O0防止内联导致断点跳过） - 检查
launch.json中sourceFileMap是否需要配置——例如在 WSL 中开发但用 Windows 版 VSCode，就得把"/home/user/project"映射到"Z:\project" - MinGW 用户注意：默认生成的 DWARF 版本可能与 VSCode 内置的
cppdbg不兼容，可尝试加编译参数-gdwarf-4 - 如果用 CMake，优先用
CMake Tools扩展自动生成配置，它会自动处理sourceFileMap和miDebuggerPath
修改代码后断点失效或变量值显示 <optimized out>
这几乎全是编译优化惹的祸。VSCode 本身不控制优化级别，它只是读取二进制里的调试信息；一旦 GCC/Clang 加了 -O1 及以上，变量可能被寄存器暂存、函数被内联、甚至整段逻辑被删掉——调试器自然看不到原始值。
- 开发阶段永远用
-O0 -g编译；发布前再切到-O2 -g（保留调试信息便于事后分析 core dump） - VSCode 的
tasks.json中，确保args数组里没有遗漏-O相关参数，尤其注意某些模板任务默认带-O2 - 如果用了 Makefile 或 Ninja，改完
CFLAGS后别忘了重新make clean && make，否则旧的优化版二进制还在 - LLDB 用户注意：
<optimized out></optimized>在某些版本中比 GDB 更频繁，可尝试升级到 LLVM 16+ 或换用gdb
Windows 下 gdb 启动卡住或提示 Unable to start debugging
Windows 原生 gdb（如 MinGW-w64 自带）和 VSCode 的 cppdbg 通信存在兼容性问题，尤其在路径含空格、中文或驱动级安全软件拦截时。这不是配置写错了，而是底层调试协议握手失败。
立即学习“C++免费学习笔记（深入）”；
- 优先改用
gdb.exe的完整绝对路径，比如"C:\mingw64\bin\gdb.exe"，避免 PATH 查找歧义 - 关闭 360、火绒等主动防御软件，它们常劫持
CreateProcess导致 gdb 子进程被阻断 - 不要把项目放在
C:Users用户名OneDrive...这类同步文件夹里——OneDrive 的文件虚拟化机制会让 gdb 打开源码文件失败 - 实在不行，换用
vscode-cpptools官方推荐的cppvsdbg（仅限 MSVC 工具链），它走的是 Windows Debug API，稳定性高得多
