launch.json是VSCode调试核心配置文件，决定F5行为，控制启动命令、工作目录（cwd）、环境变量、参数（args）、预启动任务（preLaunchTask）等；配错会导致路径错误、参数失效、调试静默失败等问题。
launch.json 是 VSCode 里真正决定“按 F5 后到底跑什么”的配置文件，不是可有可无的装饰。它不光控制启动命令，还直接干预工作目录、环境变量、参数传递、是否等待编译完成等关键行为——很多调试失败、路径报错、参数不生效的问题，根源都在这个文件没配对。
为什么改了代码却总在旧路径下运行？
常见现象：FileNotFoundError 找不到数据文件，或 ImportError 报模块不存在，但明明文件就在当前目录。根本原因通常是 cwd（current working directory）没设对。
-
cwd默认值是${workspaceFolder}，不是当前打开的文件所在目录 - 如果你在子目录里打开
train.py，但数据文件放在./data/下，而cwd还是项目根目录，那open("data/config.yaml")就会失败 - 正确做法：显式设为
"cwd": "${fileDirname}"，尤其适合单文件调试场景 - 注意：
${fileDirname}在多根工作区（multi-root workspace）中可能指向意外路径，此时建议用${workspaceFolder}+ 相对路径组合
args 参数传不进脚本？检查这三处
args 字段看着简单，但 Python 脚本里收不到参数，90% 出在这几个地方：
- 确保
program指向的是真实可执行文件，比如"program": "${file}"—— 如果你选的是"program": "python"，那args会被当成解释器参数，而不是脚本参数 - Python 脚本必须用
argparse或sys.argv主动读取，launch.json不会自动注入变量 - Windows 下路径含空格时，
args里的字符串必须手动加引号，例如"--config", "C:\My Project\config.json"，否则会被截断 - 如果用了
preLaunchTask（比如先编译），确认该任务没覆盖或干扰args的传递逻辑
type 和 request 配错了，调试器根本不会启动
type 决定用哪个调试扩展干活，request 决定怎么干——这两个字段一旦不匹配对应语言的调试器能力，F5 就只是静默失败，连错误提示都不给。
-
"type": "python"已被弃用，必须用"type": "debugpy"（需装 Python 扩展） -
"type": "cppdbg"对应 C/C++ 扩展，不能和"type": "gdb"混用 -
"request": "launch"是启动新进程；"request": "attach"是连上已有进程，后者需要额外配processId或port，别误当成通用方案 - Node.js 项目若用 ES Module，
"type": "node"可能不支持import，得换"type": "pwa-node"
preLaunchTask 编译完却还是跑旧二进制？
这是 C++ / .NET / Go 等编译型语言最常踩的坑：任务跑完了，但 program 指向的仍是上次生成的旧文件。
-
preLaunchTask只保证任务执行，不保证任务成功——如果gcc编译出错，VSCode 默认仍会继续启动调试，结果跑的是陈旧可执行文件 - 务必在
tasks.json中为该任务配置"problemMatcher"（如"$gcc"），让 VSCode 能识别编译错误并中断后续流程 -
program路径别硬编码，用${fileDirname}/a.out或${workspaceFolder}/build/app这类动态路径，避免手动更新 - Go 用户注意：
"program": "${workspaceFolder}"在 Go 模块下才有效；单文件项目得写成"program": "${file}"
launch.json 的复杂点不在语法，而在它串联了编辑器、终端、调试器、构建系统四层行为。一个字段配错，可能表现为“断点不命中”“环境变量丢失”“路径解析异常”等完全不相关的症状——排查时别只盯着报错信息，先确认 cwd、program、args、preLaunchTask 这四个字段是否彼此自洽。 
