VSCode中tasks.json用于定义构建等自动化任务，launch.json专用于调试配置；二者职责分离，tasks.json通过preLaunchTask触发构建，launch.json则依赖其输出产物进行调试。

VSCode 的快捷键不是靠背的，而是靠“场景触发”建立肌肉记忆的；调试工作流不靠堆配置，而靠 launch.json 和 tasks.json 的职责分离是否清晰。

Ctrl+P 为什么比文件树快？因为它跳的是符号索引，不是目录结构

你按 Ctrl+P 输入 “main”，它不只匹配文件名，还会查当前项目中所有 main 函数、类名、甚至注释里的关键词（取决于已启用的语言扩展）。前提是：项目有合理的语言服务器支持，比如 C/C++ 扩展启动了 cpptools，Python 扩展加载了 Pylance。

• 如果 Ctrl+P 慢或不响应，先检查状态栏右下角语言模式是否正确（如显示 “Plain Text” 而非 “C++”）
• 输入 @ 可切换到符号搜索（@main），输入 : 可跳转到行号（:42）
• 对大型 C++ 项目，Ctrl+Shift+O（符号导航）比 Ctrl+P 更准，因它只走 AST 索引，不过滤文件名

调试前必须确认的三件事：type、request、program

launch.json 里最容易写错的不是路径，而是这三个字段的组合逻辑。比如你想调试一个 CUDA 程序，"type": "cppdbg" 是必须的，但若写成 "type": "cpp"，VSCode 会静默失败——它根本不会报错，只是 F5 后直接退出。

• "type" 决定用哪个调试器插件：C++ 用 cppdbg，Node.js 用 node，.NET 用 coreclr
• "request" 是动作意图："launch" 表示启动新进程，"attach" 表示挂接到已有进程（如调试 nvcc 编译出的 .exe 时常用）
• "program" 必须是绝对路径或带变量的可解析路径，"${fileDirname}/${fileBasenameNoExtension}.exe" 比硬编码 "./a.exe" 更可靠

tasks.json 不是编译脚本，它是构建任务与调试器之间的契约

tasks.json 的核心作用，是让调试器知道“编译产物在哪”“用了什么参数”“有没有生成调试符号”。如果你在 launch.json 里写了 "preLaunchTask": "Build"，但 tasks.json 里没定义 label 为 "Build" 的 task，F5 就会卡住并弹提示“找不到任务”，而不是自动 fallback 到默认编译。

VSCode

避免常见的 VSCode 错误——设置冲突、调试器配置和扩展冲突。

下载

• Windows 下用 MSVC 编译 C++，task 的 "command" 应调用 cl.exe 或封装好的批处理（如知识库中的 cpp_cuda_unified.cmd），不能只写 g++
• 务必在 task 中设置 "group": "build"，否则 Ctrl+Shift+B 不会识别它为构建任务
• 如果编译失败但 problemMatcher 没配对（比如 MSVC 用 "$msCompile"，GCC 用 "$gcc"），错误不会出现在“问题”面板，只会卡在终端里

F5 调试失败时，第一个该看的不是代码，是调试控制台输出

按下 F5 后，底部面板会切到“调试控制台”，这里打印的是调试器自身的日志，不是你的程序 stdout。常见线索包括：

• Could not find the task 'Build' → 检查 tasks.json 的 label 和 launch.json 的 preLaunchTask 是否完全一致（含空格）
• Cannot launch program 'xxx.exe'; setting the 'cwd' property may help → 当前工作目录不对，加 "cwd": "${fileDirname}" 到 launch 配置
• Failed to launch: can't find gdb/lldb/cl.exe → 路径没进系统 PATH，或 settings.json 里 cpp.default.compilerPath 指向了错误位置

真正难调的，往往不是断点不命中，而是调试器压根没拿到符号表——比如用 Release 模式编译、忘了加 -g 或 /Zi，或者 launch.json 里 "miDebuggerPath" 指向了一个不兼容的 GDB 版本。