launch.json是VS Code调试唯一权威配置文件，必须从项目根目录.vscode/launch.json手动提取，不可通过Settings Sync或导出设置获取；工作区级配置优先于用户级，且依赖program路径、env、preLaunchTask等字段完整有效。
调试配置不能靠 Settings Sync 或「导出设置」按钮获取，launch.json 是唯一权威来源，它必须从工作区或用户级 .vscode/ 目录手动提取，否则调试器根本找不到启动参数。
怎么找到真正的 launch.json 文件
VSCode 的调试配置分两级：工作区级（项目根目录下的 .vscode/launch.json）和用户级（全局默认，极少使用）。绝大多数人用的是前者，但常误以为「设置 → 打开设置 (JSON)」能导出它——那只是 settings.json，跟调试无关。
- 工作区调试配置一定在你项目的根目录下：
.vscode/launch.json。打开终端，执行ls -la .vscode/确认该文件存在 - 如果项目没这个文件，说明你还没配置过调试器，或用的是「快速调试」临时生成的隐式配置（不会落盘，无法导出）
- 用户级
launch.json位置是：%APPDATA%CodeUser（Windows）、$HOME/Library/Application Support/Code/User/（macOS）、$HOME/.config/Code/User/（Linux），但几乎没人放这里，除非你明确改过全局调试模板
launch.json 导出后为什么调试不生效
常见现象是文件复制过去，F5 启动却报错「Can't find the configuration」或直接跳过调试。核心原因不是路径错，而是 VSCode 对 launch.json 的加载有强上下文依赖：
- 路径硬编码未清理：
"program": "${workspaceFolder}/build/main.elf"这类字段在新机器上若没有相同目录结构，GDB 就会找不到固件；RISC-V 开发中尤其常见 - 调试器可执行路径写死：
"miDebuggerPath": "C:\tools\riscv64-elf-gdb.exe"换到 macOS/Linux 必然失败，应改用"miDebuggerPath": "riscv64-unknown-elf-gdb"并确保已加入PATH - 环境变量缺失：
"env": { "PATH": "C:\tools\bin;${env:PATH}" }这种 Windows 专属写法在其他平台会静默失效，建议删掉或拆成跨平台条件分支 - 插件未安装：
"type": "cppdbg"或"type": "cortex-debug"要求对应插件已启用，否则 VSCode 根本不识别该配置块
运行环境备份必须包含哪些东西
只导出 launch.json 不等于备份了运行环境。一个可复现的嵌入式或本地服务调试链路，至少要覆盖三类实体：
-
.vscode/launch.json：调试入口，含configurations数组、preLaunchTask引用名 -
.vscode/tasks.json：定义构建命令，比如riscv64-unknown-elf-gcc编译步骤，否则preLaunchTask会报错找不到任务 - 工具链本身是否在
PATH中：VSCode 不打包 GDB、OpenOCD、JLinkExe 等二进制，得在目标机确认which riscv64-unknown-elf-gdb有输出 - （可选但强烈建议）
.vscode/extensions.json：声明必需插件，例如{"recommendations": ["marus25.cortex-debug", "ms-vscode.cpptools"]}，避免靠记忆重装
如何验证调试配置真正可迁移
别等换机器才试。最有效的验证方式是在干净容器里跑一次：
- 用 Docker 启一个空 Ubuntu 镜像：
docker run -it --rm -v $(pwd):/workspace ubuntu:22.04 - 在容器内安装 VSCode Server（或用 Remote-Container）、对应插件、工具链
- 把你的
.vscode/目录复制进去，再执行code /workspace --no-sandbox --disable-gpu - 观察左下角是否出现「Run and Debug」面板，且配置列表里有你的 launch 项 —— 有，才算导出成功
很多人卡在 tasks.json 和工具链路径的耦合上，以为导出了 JSON 就万事大吉，其实调试器启动失败八成是因为构建命令先崩了。
