能用Ctrl+B编译、Ctrl+Shift+B运行C文件，说明MinGW和Sublime连接已通；90%失败源于系统未识别gcc，须先在命令行验证gcc --version成功，再配置Sublime，否则所有设置无效。
能用 Ctrl+B 编译、Ctrl+Shift+B 运行 C 文件，说明 MinGW 和 Sublime 的连接已经打通。90% 的失败不是配置错，而是系统根本没认出 gcc —— 先在命令行跑通 gcc --version，再动 Sublime。
验证 gcc 是否真可用
这步跳过，后面所有配置都白搭。打开 CMD 或 PowerShell，直接输：
gcc --version
如果报 'gcc' is not recognized，别急着改 Sublime 配置，检查三件事：
- MinGW-w64 是否装的是 x86_64-win32-seh 版（不是旧版 MinGW，也不是 posix 线程）
- 安装时是否勾选了 “add to PATH”，或手动把
C:\mingw64\bin加进了系统环境变量 PATH - 加完 PATH 后，是否**重启了命令行和 Sublime Text**（PATH 变更不会热加载）
路径里含中文、空格、括号（比如 C:\Program Files\...）也会导致 gcc 找不到，建议解压到纯英文无空格路径，例如 C:\mingw64。
立即学习“C语言免费学习笔记（深入）”；
Windows 下创建 C.sublime-build 的关键字段
Sublime 不会自动猜你用什么命令，必须写清楚怎么调 gcc、怎么传参、怎么运行。新建构建系统（Tools → Build System → New Build System…），贴入以下内容并保存为 C.sublime-build（放在 %APPDATA%\Sublime Text\Packages\User\）：
{
"shell_cmd": "gcc -Wall -g -static \"$file\" -o \"$file_base_name\"",
"file_regex": "^(..[^:]*):([0-9]+):?([0-9]+)?:? (.*)$",
"working_dir": "$file_path",
"selector": "source.c",
"variants":
[
{
"name": "Run",
"shell_cmd": "gcc -Wall -g -static \"$file\" -o \"$file_base_name\" && \"$file_path/$file_base_name\""
}
]
}
注意几个硬性要求：
-
"shell_cmd"必须带"shell": true（上面示例省略了，是因为 Windows 默认启用 shell；macOS/Linux 必须显式写"shell": true） -
-static要加上，否则运行时报 DLL 缺失（libgcc_s_seh-1.dll等） -
-Wall和-g别省，前者开全部警告，后者保留调试信息，后续用 gdb 或插件调试才有效 -
file_regex用来让错误定位到行号，不配它，报错就只显示一串文字，没法双击跳转
为什么 Ctrl+Shift+B 选 Run 没反应或闪退
常见于需要交互输入的程序（比如 scanf），Sublime 自带输出面板不支持 stdin 输入，且执行完立即关闭。这不是配置错，是设计如此。解决方法只有两个：
- 把 Run 变体改成调用外部终端：把
"shell_cmd"改成cmd /c gcc ... && start cmd /c \"$file_path/$file_base_name & pause\"（Windows） - 装插件
Terminus，它提供可交互的终端面板，比原生输出面板靠谱得多
另外注意：Run 变体里不能用 ./$file_base_name，Windows 不认 ./，必须写全路径 $file_path/$file_base_name；路径含空格时，"$file_path/$file_base_name" 的引号也不能少。
编译成功但运行报错“找不到入口点”或“不是有效的 Win32 应用程序”
这是 MinGW 架构和目标平台不匹配的典型表现。比如你装的是 x86_64-posix-seh，但项目里用了 Windows API 的某些特性，或链接了 32 位库。最稳做法是统一用 x86_64-win32-seh 版本，并确保没混用不同线程模型（posix vs win32）的工具链。另一个隐藏坑是：如果你之前装过 TDM-GCC 或 Code::Blocks 自带的 MinGW，它们可能残留 PATH，导致 Sublime 实际调用的是旧版本 gcc —— 运行 where gcc 查看实际调用路径，比只信 gcc --version 更可靠。
