答案是Sublime中g++“command not found”源于GUI启动未继承shell环境变量。需验证终端g++ --version是否真可用，Windows须将MinGW-w64的bin目录加入系统PATH并重启Sublime，macOS需用实际命令名如g++-14，Linux/WSL2须使用Linux版Sublime且which g++有输出。
g++命令在终端能跑，但Sublime里Ctrl+B报“command not found”
这不是Sublime配置错了，而是GUI启动时根本没继承你的shell环境变量。Windows用户装MinGW-w64后没勾选“Add to PATH”，或macOS用Homebrew装的gcc实际叫g++-14（不是g++），都导致Sublime找不到命令。
- Windows：打开CMD，执行
g++ --version；若失败，手动把C:\mingw64\bin加进系统PATH，重启Sublime - macOS：终端运行
ls /opt/homebrew/bin/g++*确认真实命令名，构建系统里必须写g++-14（版本号依实际而定） - Linux/WSL2：确保用的是Linux版Sublime，且
which g++有输出；别用Windows版Sublime去调WSL里的g++
单文件能编译，多.cpp文件直接报错找不到函数定义
Sublime默认的Build System只处理当前打开的${file}，不会自动扫描同目录下的其他.cpp或.h文件。硬改shell_cmd拼一堆源文件名既易出错，又无法处理头文件依赖和增量编译。
- 不要在
shell_cmd里写g++ a.cpp b.cpp main.cpp -o app——路径含空格、文件名含特殊字符时大概率失败 - 别指望
file_regex能解析多文件编译的混合错误输出，跳转会乱 - 真正可行的方案只有两个：写Makefile，或换用VS Code+CppTools
- 最小可用Makefile示例（保存为
Makefile在同一目录）：CC = g++-14<br>CFLAGS = -std=c++17 -Wall<br>app: main.o utils.o<br>\t$(CC) $(CFLAGS) -o $@ $^<br>%.o: %.cpp<br>\t$(CC) $(CFLAGS) -c $< -o $@<br>.PHONY: clean<br>clean:<br>\trm -f *.o app
想用Ctrl+B直接编译整个项目，但Build System不认Makefile
Sublime本身不解析Makefile，但可以调用make命令。关键在于让Build System正确切换到项目根目录，并传参控制目标。
- 新建
Make.sublime-build，内容用cmd数组更稳（尤其Windows）：{<br> "cmd": ["make", "-C", "${project_path}", "app"],<br> "working_dir": "${project_path}",<br> "selector": "source.c++, source.cpp",<br> "file_regex": "^(.+):([0-9]+):([0-9]+): (.*)$"<br>} -
${project_path}要求你已通过Project → Save Project As…保存过项目；否则 fallback 到${file_path} - 如果Makefile放在子目录（如
src/Makefile），把-C参数改成-C src - macOS/Linux下
make通常自带；Windows需确认MinGW-w64的bin/里有make.exe，否则要单独装
调试时断点不生效，或者GDB报“no debugging symbols”
默认g++编译不带调试信息，GDB自然无从下手。Sublime没有内置调试器，必须靠外部工具链配合。
立即学习“C++免费学习笔记（深入）”；
- Makefile里加
-g标志：CFLAGS = -std=c++17 -Wall -g - 确保
make clean后再make，否则旧的无符号可执行文件还在 - 调试操作得脱离Sublime：终端进项目目录，执行
gdb ./app，再用break main、run等命令 - 真想在Sublime里点点断点，只能装
Terminus插件，在内嵌终端里手动跑gdb，别信“一键调试”类插件——它们基本不维护了
make，但不管理依赖；能高亮g++错误，但不解析#include路径。越想让它扛大项目，越容易卡在路径、编码、环境变量这些底层细节上。 
