Atom运行C代码需本地gcc可用且被插件识别，优先验证gcc --version输出；再选gpp-compiler（单文件F5）或build插件（多文件需.atom-build.yml配置），注意PATH、重启Atom、英文路径及编码问题。
Atom 本身不是 IDE，也不自带编译器；它运行 C 代码完全依赖外部工具链（如 gcc）和插件协作。能不能跑起来，核心就看两件事：你本地有没有可用的 gcc（或 clang），以及插件是否能正确调用它。
确认 gcc 是否已就绪并被 Atom 找到
这是最容易卡住的第一步。很多用户装了 MinGW 或 MSYS2，但没把 gcc.exe 所在目录加进系统 PATH，或者加了却没重启 Atom —— 插件就根本看不到编译器。
- 在终端（Windows CMD/PowerShell、macOS Terminal、Linux shell）中执行
gcc --version，必须有输出；否则 Atom 插件调用时会报command not found或spawn gcc ENOENT - Windows 用户尤其注意：MinGW 安装后默认路径可能是
D:\MinGW\bin或C:\msys64\mingw64\bin，复制该路径，在系统环境变量Path中新增一行，**保存后必须重启 Atom** - Linux/macOS 用户若用 Homebrew 安装了
gcc，注意 macOS 自带的clang不叫gcc，需确认which gcc是否指向真实 GNU 编译器；否则插件可能静默失败
选对插件：gpp-compiler vs build + .atom-build.yml
gpp-compiler 简单粗暴，适合新手快速验证；build 插件更灵活，适合多文件项目或需要自定义编译参数的场景。两者不兼容，别同时启用。
-
gpp-compiler：安装后按F5即可编译运行当前.c文件，但只支持单文件、固定参数（gcc -o a.out file.c && ./a.out），无法传参、无法调试、不识别#include "xxx.h"的相对路径 -
build插件：需手动建.atom-build.yml配置文件，例如：cmd: "gcc" args: ["-Wall", "-std=c11", "-o", "{FILE_ACTIVE_PATH}/{FILE_ACTIVE_NAME_BASE}", "{FILE_ACTIVE}"] sh: true cwd: "{FILE_ACTIVE_PATH}"这样能加警告、指定标准、避免覆盖同名可执行文件；但一旦yml里写错引号或缩进，F9就直接没反应，且错误提示极不明显
常见报错与绕过方式
插件报错往往不告诉你具体哪错了，只显示“Build failed”或空白输出栏。得靠反向排查：
立即学习“C语言免费学习笔记（深入）”；
-
undefined reference to `main'：文件扩展名不是.c，或右下角语言模式没设成C（点击 Atom 窗口右下角文字，选C） - 中文路径或空格导致编译失败：Atom 传给
gcc的{FILE_ACTIVE}是带空格的绝对路径，gcc会截断；解决方法是把项目放纯英文无空格路径，如C:\code\hello\test.c - 输出中文乱码（Windows）：
gpp-compiler默认用系统 ANSI 编码运行gcc，但终端是 UTF-8；临时解法是在命令行先执行chcp 65001，再启动 Atom；长期建议换用build插件 + 自定义sh: true调用 PowerShell
真正麻烦的从来不是按哪个键，而是插件背后那层「谁调用谁」「路径怎么传」「编码怎么转」的隐式约定。哪怕 gcc 装对了、插件装对了，一个没重启 Atom、一个文件路径带中文、一个 yml 缩进多了一格，都会让 F5 变成哑巴按钮 —— 这些细节不试一遍，光看教程永远卡在“为什么我点不动”。
