Ctrl+Shift+B没反应的根源是make命令不可用；需先在VSCode终端执行make --version验证，Windows确保mingw32-make.exe在PATH，macOS/Linux必须用code .启动以继承shell PATH，tasks.json中command写"make"或"mingw32-make.exe"，配"group":"build"、"isDefault":true和"problemMatcher":["$gcc"]，launch.json的program路径须与Makefile输出严格一致。
Ctrl+Shift+B 没反应？先确认 make 命令是否真可用
VSCode 不自带 make，它只是调用系统命令。如果 Ctrl+Shift+B 按下后毫无反应，或弹出 Command 'make' not found，问题几乎一定出在环境路径上，不是配置写错了。
- 在 VSCode 集成终端里手动执行
make --version，失败就别继续配tasks.json了 - Windows 用户：确保
mingw32-make.exe或make.exe在 PATH 中；用 MSYS2 的话，优先选mingw64\bin\make.exe，别混用 PowerShell 和 MSYS2 bash - macOS/Linux 用户：必须从终端启动 VSCode（
code .），双击图标会丢失 shell 初始化文件（如~/.zshrc）里设的 PATH
tasks.json 里 command 写成 "make" 就够了，别加路径
硬写绝对路径（比如 "command": "/usr/bin/make"）看似稳妥，实则破坏可移植性——换机器、换用户、换工具链位置就失效。VSCode 只需依赖 PATH 查找，这才是标准做法。
-
"command": "make"（Linux/macOS）或"command": "mingw32-make.exe"（Windows MinGW）是唯一推荐写法 -
"args"控制目标，例如["DEBUG=1", "build"]；若 Makefile 在src/下，必须加"options": {"cwd": "${workspaceFolder}/src"} - 必须含
"group": "build"且"isDefault": true，否则Ctrl+Shift+B不触发 - 必须配
"problemMatcher": ["$gcc"]，否则编译错误只显示红字，点不开、跳不到源码行
launch.json 的 program 路径必须和 Makefile 输出严格一致
VSCode 调试器（GDB/LLDB）完全不读 Makefile，它只认 program 字段指向的二进制文件。路径错一格、名字差一个字母，就会报 Cannot find executable file 或断点变空心圆。
- 检查 Makefile 里
gcc -o或$(CC) -o后面写的输出路径，比如./build/app，那launch.json里的"program"就得写成"${workspaceFolder}/build/app" - 确保 Makefile 的
CFLAGS或CXXFLAGS包含-g，否则调试时变量不可见、断点无效 - 如果用了
preLaunchTask，它的label必须和tasks.json中对应 task 的label完全一致（大小写敏感）
多目标、条件编译、子目录工程，靠 args 和 cwd 组合解决
Makefile 本身支持任意复杂逻辑，VSCode 只需把参数正确传过去。没必要为了“适配 VSCode”去改 Makefile 结构，那是本末倒置。
- 要切 release 模式？
"args": ["RELEASE=1", "all"]即可，Makefile 里用ifeq ($(RELEASE),1)分支处理 - Makefile 放在
build/目录？加"options": {"cwd": "${workspaceFolder}/build"}，不用改任何 Makefile 内容 - 想一键 clean + build？
"args": ["clean", "all"]，前提是 Makefile 里all: clean或类似依赖已定义 - 注意：多个
args项会被 shell 当作独立参数传递，["DEBUG=1 build"]是错的，应写成["DEBUG=1", "build"]
problemMatcher 和 preLaunchTask 的联动细节——它们不报错，但一旦漏配或拼写错一个字符，错误定位和自动重编译就彻底失效，而你可能花半小时才意识到是 JSON 字段名写成了 problemMathcer。 
