sublime text 本身不解析 makefile，只调用系统 make 命令；能否跨平台编译、多目标协同工作，取决于 makefile 写法是否健壮，以及 sublime 是否能正确继承对应平台的工具链路径。makefile 必须显式声明 .phony 和平台适配逻辑，working_dir 和 path 必须精确指向项目根与工具链，file_regex 需匹配 gcc/clang 实际报错格式，variants 中禁用 && 连接命令，windows 下需处理 .exe 后缀及 mingw32-make 差异。
Sublime Text 本身不解析 Makefile，只调用系统 make 命令；能否跨平台编译、多目标协同工作，取决于 Makefile 写法是否健壮，以及 Sublime 是否能正确继承对应平台的工具链路径。
Makefile 必须显式声明 .PHONY 和平台适配逻辑
默认情况下，make 把目标名当文件名检查，若恰好存在同名文件（比如 clean 目录），就会跳过执行。所有非文件型目标必须用 .PHONY 声明：
-
.PHONY: clean test run deploy—— 否则 Windows 下make clean可能静默失败 - 跨平台时避免硬编码路径分隔符：用
$(shell pwd)（Linux/macOS）或$(shell cd)（Windows CMD）不如统一用$(CURDIR)，它被所有主流 make 实现支持 - Windows 下可执行文件后缀需显式处理：
$(TARGET).exe而非$(TARGET)；构建规则里调用时也得写全./$(TARGET).exe - MinGW 用户注意：
make实际命令可能是mingw32-make，Makefile 里别假设make就是 GNU make，尤其在$(MAKE)递归调用时
Sublime 构建系统中 working_dir 和 path 必须精确指向项目根与工具链
working_dir 错了，make 就找不到 Makefile；path 错了，g++ 或 mingw32-make 就根本跑不起来——这两项出错，90% 的“Ctrl+B 没反应”就源于此。
-
"working_dir": "${project_path:${folder:${file_path}}}"是最稳写法：无论你打开的是单个Makefile、整个文件夹，还是没开项目直接编辑源码，都能定位到含 Makefile 的目录 - 不要依赖系统 PATH：macOS/Linux 上 Sublime GUI 启动时不读
~/.zshrc；Windows 上 MinGW 安装时勾选了 “Add to PATH”，但 Sublime 可能仍拿不到——显式写"path": "/usr/local/bin:/opt/homebrew/bin"或"path": "C:\MinGW\bin;C:\msys64\usr\bin" - Windows 下若用 MSYS2/MinGW-w64，
make命令实际是mingw32-make.exe，构建系统里得写成["mingw32-make"]，不能只写["make"]
file_regex 不匹配 GCC/Clang 标准格式，错误就无法跳转
双击错误行没反应？不是插件问题，大概率是 file_regex 没对上编译器真实输出。GCC 和 Clang 默认报错格式是 main.cpp:12:5: error: …，但不同版本、不同平台略有差异。
- 最通用写法：
"file_regex": "^(.+):([0-9]+):([0-9]+):\s+(warning|error):\s+(.*)$"—— 匹配警告和错误，且容忍空格和冒号后空格 - Clang on macOS 可能输出
note:行，但 Sublime 不跳转 note，不用额外匹配 - Windows CMD 下若用 PowerShell 作 shell，
file_regex仍按输出文本匹配，跟 shell 类型无关；但shell_cmd模式下要确保引号嵌套正确，否则整个命令解析失败 - 如果用了自定义编译器包装脚本（如
ccache g++），输出格式可能变化，建议先在终端跑make 2>&1 | head -n 5看真实前几行
variants 里别用 && 连接命令，JSON 数组不支持 shell 语法
想一键 make && ./myapp？直接写 ["make", "&&", "./myapp"] 会失败——JSON cmd 数组是逐字传参给 execve()，&& 是 shell 特性，不会被识别。
- 正确做法一（推荐）：改用
"shell_cmd": "make && ./myapp"，并删掉cmd字段；此时shell: true可省略（默认为 true） - 正确做法二：拆成两个 variants，一个
make，一个run，避免耦合；尤其在调试阶段，编译失败时不该强行运行 - Windows 下
./myapp得换成myapp.exe；若用 MSYS2，路径前缀可能含/c/path/to/app，最好统一用$(CURDIR)/myapp.exe在 Makefile 里生成 - 别在 variants 里写
make clean && make：clean 是破坏性操作，应单独触发；多次构建之间状态不一致时，反而掩盖依赖问题
真正难的不是写构建系统，而是让 Makefile 在不同 shell、不同 make 实现、不同 PATH 环境下都保持行为一致——.PHONY、$(CURDIR)、显式工具名、独立 targets，这些细节漏掉任何一环，跨平台就变成玄学。
