VSCode本身无内置“开发者工具”，需配置编译器、调试器等外部工具，参数集中于tasks.json（编译）、launch.json（调试）、c_cpp_properties.json（智能提示）等JSON文件；配错对象或层级（用户级vs工作区级）即失效。
VSCode 本身没有“开发者工具”这个内置模块——你真正要配的，是它背后依赖的编译器、解释器、调试器和语言服务器，而所有参数都落在几个关键 JSON 文件里。搞错对象（比如以为在“开发者工具”里调设置），配置就永远对不上。
怎么确认 VSCode 正在用哪个 Python 解释器
很多人改了 settings.json 或装了 Anaconda，却还是报 ModuleNotFoundError，问题往往出在解释器没切对。
- 按
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS），输入Python: Select Interpreter，回车 - 列表里出现的路径必须指向你期望的环境，比如
C:\Users\name\anaconda3\python.exe或/opt/homebrew/bin/python3.11 - 如果只看到系统默认的
/usr/bin/python3，说明 PATH 没生效，或你根本没装那个解释器 - 选中后，VSCode 底部状态栏左下角会显示当前解释器路径；不显示？说明没生效，重启窗口再试
为什么 c_cpp_properties.json 里 includePath 配了还是找不到头文件
这个文件不是“写完就生效”的静态配置，它控制的是 IntelliSense（代码补全/跳转/错误提示）行为，不参与实际编译。常见失效原因：
-
includePath中用了相对路径但没加${workspaceFolder}前缀，比如写成"include"而不是"${workspaceFolder}/include" - 配置的
compilerPath指向了错误的 GCC 版本（如gcc-13却没装，或指向了clang却在用 MinGW 编译） - 你改的是用户级
c_cpp_properties.json，但项目里已有工作区级同名文件，后者优先级更高 - Mac 上通过 Homebrew 装的 GCC，头文件路径通常是
/opt/homebrew/include，但默认配置不会自动包含它，得手动加进去
tasks.json 和 launch.json 的核心区别与误用点
这两个文件常被混用，但职责完全不同：前者管“怎么编译”，后者管“怎么启动并调试”。写反或漏掉关键字段，就会出现“能编译不能调试”或“调试时找不到可执行文件”。
-
tasks.json中args是传给编译器的参数，比如["-g", "-Wall", "${file}"]；别把它和launch.json的args（传给程序本身的运行参数）搞混 -
launch.json的program字段必须是**已编译好的可执行文件路径**，不是源文件（${file}错！），也不是相对路径（如"./a.out"不稳定，推荐"${fileDirname}/${fileBasenameNoExtension}"） - Windows 下用 MinGW 编译 C++，
launch.json的miDebuggerPath必须指向gdb.exe，而不是gcc.exe；路径错则调试直接失败，报错Cannot launch program; spawn gdb.exe ENOENT - 如果你用 Code Runner 插件一键运行，它根本不读
tasks.json或launch.json，而是走自己那套规则——想统一行为，就别混用
最常被忽略的其实是工作区与用户配置的层级关系：.vscode/ 下的配置只对当前文件夹生效，而全局设置在 settings.json（用户级）里。改了一堆参数没反应？先看右下角有没有“工作区”标识，再检查你编辑的到底是哪一层的文件。
