根本原因是编译器未就位、路径变量写法错误或保存位置不对；需先验证gcc --version可用，再将C.sublime-build文件存至Packages/User/目录，用shell_cmd配置并确保${file}等变量完整、文件已保存且语法设为C。
能新建，但直接点 New Build System… 粘贴网上配置大概率跑不起来——根本原因不是 JSON 写错了，而是编译器没就位、路径变量写法不对、或保存位置错误。
确认 gcc 已装且 PATH 可见
这是所有后续操作的前提。Sublime Text 不自带编译器，它只负责调用系统命令。gcc --version 必须在终端（CMD/PowerShell/Terminal）里能直接执行并返回版本号，比如 gcc (MinGW-W64) 13.2.0。
常见失效场景：
- Windows 用户装了 MinGW-w64，但安装时没勾选 “Add to PATH”，或手动添加环境变量时路径写成了
C:\mingw64\bin却漏掉末尾的\bin - macOS 用户用 Homebrew 装了 GCC，实际命令是
gcc-14，但配置里硬写了gcc - Linux 用户没装
build-essential（Ubuntu/Debian），只装了gcc但缺cpp、as等配套工具
创建 C.sublime-build 文件的三处硬性要求
Sublime 只认 Packages/User/ 目录下的 .sublime-build 文件。点菜单 Tools → Build System → New Build System… 后，必须手动保存到这个路径，否则重启就消失。
关键细节：
- 文件名必须是
C.sublime-build（不能带空格、中文、下划线，也不能叫untitled） - 编码必须为
UTF-8 without BOM（Windows 下用记事本另存为时容易误选成“UTF-8”带 BOM，会导致解析失败） -
selector字段必须是"source.c"，否则新建.c文件后不会自动关联该构建系统
shell_cmd 和 cmd 的选择逻辑
Windows 下优先用 shell_cmd；macOS/Linux 推荐用 cmd 数组格式。二者不能混用，且行为差异极大：
-
shell_cmd是字符串，交由系统 shell 解析，支持&&、|、引号包裹路径等，适合单文件快速测试 -
cmd是数组，参数逐个传给程序，绕过 shell，更安全但写法严格：Windows 下若想运行可执行文件，必须显式加"shell": true，否则["start", "cmd", "/c", "a.exe"]会失败 - 别在
shell_cmd里写"shell": true——它默认走 shell，加了反而可能破坏 PATH 传递
一个最小可用的 Windows 配置示例（保存为 C.sublime-build）：
{
"shell_cmd": "gcc -Wall -std=c17 \"${file}\" -o \"${file_path}/${file_base_name}.exe\"",
"file_regex": "^(..[^:]*):([0-9]+):?([0-9]+)?:? (.*)$",
"working_dir": "${file_path}",
"selector": "source.c"
}
为什么 Ctrl+B 没反应？先盯住这三点
90% 的“没反应”问题出在这三个地方，而不是配置本身：
- 当前文件未保存（
${file}变量为空，gcc 收不到输入路径） - 文件语法未设为 C（右下角状态栏显示不是
C，而是Plain Text或其它；快捷键Ctrl+Shift+P→ 输入Set Syntax: C） - 构建系统没手动启用（
Tools → Build System里必须勾选你刚建的C，否则默认走空构建或 Python）
真正容易被忽略的是：${file} 和 ${file_path} 中的 $ 符号不能漏，旧文档常错写成 $file；而 variants 里的 Run 若要支持交互输入（比如 scanf），就不能依赖输出面板，得调用外部终端——这点很多人配完发现程序一闪而过，却不知道是因为 Sublime 的输出面板根本不提供 stdin 流。
13万字C语言保姆级教程（深入）：立即使用
在学习笔记中，你将探索c语言的核心概念和高级技巧！
