Sublime Text通过构建系统调用外部编译器实现C/C++一键编译运行，核心是配置.sublime-build文件：Windows用cmd、macOS/Linux用shell_cmd；需确保编译器已安装并加入PATH；避免中文路径；多文件项目宜用Makefile或Terminus插件；-std=等选项须置于源文件名前。
Sublime Text 本身不编译代码，它靠构建系统（sublime-build）调用外部编译器（如 gcc、g++、clang）完成编译运行。优化的关键不是“让 Sublime 更快”，而是让构建命令更可靠、更贴合实际开发节奏，避免每次改完代码都要切终端、手动清理、反复输参数。
构建系统里 shell_cmd 和 cmd 到底该用哪个
Windows 上必须用 cmd，Linux/macOS 推荐用 shell_cmd。原因很简单：cmd 是直接传给 Windows 命令解释器的字符串，不支持管道、重定向、多命令串联；而 shell_cmd 会走系统的 /bin/sh 或 zsh，能写 g++ ${file} -o ${file_base_name} && ./${file_base_name} 这种一行跑完编译+执行的链式命令。
- Windows 用户如果硬用
shell_cmd，会遇到'sh' is not recognized错误 - macOS/Linux 用户用
cmd，则无法使用&&、;等 shell 特性，得拆成多个构建步骤 - 跨平台统一方案：只用
cmd，但把逻辑封装进脚本（如build.sh或build.bat），再让构建系统调用它
中文路径/文件名导致 gcc 报错：invalid argument
这是 Windows 下 MinGW-w64 最常卡住新手的地方。根本原因是 MinGW 的 C 运行时不兼容 UTF-8 路径（哪怕系统 locale 是中文），一碰到带中文的 ${file} 就直接崩。不是编码设置能解决的，得绕开。
- 最稳做法：把项目放在纯英文路径下，比如
D:\code\cpp\hello.cpp，彻底避开问题 - 临时折中：在构建系统里用
${file_path}+cd切目录，再用${file_name}编译，避免路径参与命令拼接 - 别碰
chcp 65001或修改系统 locale——它会让终端输出乱码，且对构建系统无效
多文件项目怎么不手动挨个编译
单靠 ${file} 只能编译当前打开的文件，没法处理 main.cpp + utils.cpp + utils.h 这类结构。你需要让构建系统知道“这一组文件属于同一个程序”。
- 简单项目：写个
Makefile放在项目根目录，构建系统里用cmd调make（Linux/macOS）或mingw32-make（Windows） - 无 Makefile 时：用
shell_cmd配合 glob，比如g++ *.cpp -o program && ./program（注意*.cpp不包含头文件，且会编译所有 cpp，慎用于大项目） - 真正可靠的方案：配合
Terminus插件，在构建后自动打开终端并执行命令，把控制权交还给人——毕竟有些依赖顺序、链接选项的场景，编辑器真不适合全自动
sublime-build 里加 -std=c++17 没生效？
不是参数写错了，是位置不对。g++ 对参数顺序敏感：语言标准选项（-std=）必须放在源文件名之前，否则会被忽略。错误写法：g++ hello.cpp -std=c++17；正确写法：g++ -std=c++17 hello.cpp。
- 检查你的
cmd字段，确保所有-std=、-I、-L、-l这类编译/链接选项都在${file}或*.cpp之前 - 如果用了
shell_cmd并带&&，注意-std=只作用于前面的g++命令，不会影响后面的./a.out - 调试技巧：在构建系统里加
"quiet": false，看完整命令行输出，一眼就能发现参数是否被吃掉
最常被忽略的一点：构建系统不是 IDE，它不维护项目状态、不缓存依赖关系、也不感知头文件变更。你改了 utils.h 却只编译 main.cpp，出问题不是构建系统的问题，而是你没把它当构建系统用——它只是帮你少敲几个字的快捷方式，不是替代 make 或 CMake 的工具。
