断点不生效、调试器启动失败等问题主因是launch.json配置错位：type必须与已启用扩展id完全匹配（如cortex-debug不能写cppdbg），program/exe­cutable字段不可互换（cppdbg用program，cortex-debug用executable），prelaunchtask值须与tasks.json中label严格一致，stopatentry与runtoentrypoint按调试器类型区分使用。

断点不生效、调试器启动失败、程序一闪而过——这些问题基本都出在 launch.json 配置错位，而不是代码本身。

为什么改了 launch.json 还是连不上调试器？

最常见原因是 type 和实际安装的调试扩展不匹配。比如你装的是 cortex-debug，但 launch.json 里写的是 "type": "cppdbg"，VS Code 就会静默忽略这个配置，转而尝试用默认 C++ 调试器，结果自然失败。

• type 必须和已启用的调试扩展 ID 完全一致：STM32 用 cortex-debug，Python 用 debugpy，Node.js 用 node，不能凭印象缩写或拼错
• 检查扩展是否启用：打开 VS Code 扩展面板（Ctrl+Shift+X），搜索对应调试器，确认状态是“已启用”而非“已禁用”或“未安装”
• 如果同时装了多个同类扩展（如 ms-vscode.cpptools 和 marus25.cortex-debug），VS Code 可能选错；建议禁用不用的调试器

program 和 executable 到底该用哪个？

这是 C/C++ 和嵌入式开发中最容易混淆的字段。它们不是同义词，也不能互换：

Comprehensive Three.js 3D graphics reference

详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。

下载

• program 是 cppdbg 类型专用字段，指向编译生成的可执行文件（如 ${workspaceFolder}/build/app.out）
• executable 是 cortex-debug 类型专用字段，同样指向 ELF 文件，但必须是带调试符号的版本（如 ${workspaceFolder}/build/Debug/SmartFarm.elf）
• 填错字段名会导致调试器找不到目标文件，报错信息常为 Cannot find executable specified in launch.json 或直接卡在 “Launching…”

preLaunchTask 不运行？检查这三处

很多用户希望点击 F5 后自动编译再调试，但 preLaunchTask 常被设成摆设。问题往往不在任务本身，而在连接逻辑上：

• preLaunchTask 的值必须和 tasks.json 中某个 label 字段**完全一致**（包括大小写和空格），例如 "preLaunchTask": "build-stm32" 对应 "label": "build-stm32"
• tasks.json 中该任务的 type 推荐设为 "shell"，避免 Windows 上 "process" 因路径解析失败而静默跳过
• 如果构建命令依赖环境变量（如 ARMGCC_PATH），需在 tasks.json 的 options.env 中显式声明，launch.json 中的 env 不会透传给构建任务

stopAtEntry 和 runToEntryPoint 别混用

这两个字段看起来功能相似，实则适用场景完全不同，混用反而导致断点失效：

• stopAtEntry 是 cppdbg / debugpy 等通用调试器字段，设为 true 会让程序停在 main 入口第一行（C/C++）或模块顶层（Python）
• runToEntryPoint 是 cortex-debug 专用字段，值是字符串（如 "main" 或 "Reset_Handler"），它控制 OpenOCD 烧录后跳转并暂停的位置
• 对 STM32 项目，runToEntryPoint 更可靠；若误用 stopAtEntry，可能因符号未加载而根本停不住

真正卡住调试的，往往不是芯片或线缆，而是 launch.json 里一个字段名拼错、一个路径少了个斜杠、或者一个扩展没启用。调试配置不是一次写完就不管，而是每次换芯片型号、换调试器、甚至换 VS Code 版本后，都得重新核对 type、executable、configFiles 这三个字段是否依然匹配当前工具链。