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 到默认编译。
- 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 版本。
