gcc报错分四类：找不到文件、语法/语义错误、链接失败、参数不识别；需先定位类型再处理，而非盲目改代码。
绝大多数 GCC 报错可归为四类：找不到文件、语法/语义错误、链接失败、编译器不认参数。先定位报错类型，再针对性处理，别一上来就改代码。
gcc: error: xxx.c: No such file or directory
这是最直白的路径/文件名问题，不是编译逻辑出错。gcc 根本没看到源文件，后续步骤全跳过。
- 用
ls -l确认当前目录下是否存在该文件，注意大小写（Linux 区分main.c和Main.C） - 检查是否在错误目录执行命令——
cd到源文件所在目录，或补全相对/绝对路径：gcc ./src/hello.c - 终端里按
Tab键自动补全文件名，避免手输拼写错误
undefined reference to 'xxx'
编译通过了，但链接阶段失败。说明函数声明了、调用了，但最终没找到它的实现体（定义）。
- 常见于调用标准库外的函数：比如用了
pthread_create()却没加-lpthread；用了sqrt()却没加-lm - 自己写的函数没被编译进目标文件：确认
.c文件是否传给了gcc命令，或是否漏加了-c导致只生成 .o 没参与链接 - 静态库链接顺序错误：依赖 A 的 B 要放在命令行靠后位置，即
gcc main.o libB.a libA.a，否则链接器可能丢弃未立即用到的符号
error: unrecognized command line option '-std=gnu17'
编译器版本太老，不认识你写的选项。这不是代码问题，是环境不匹配。
- 运行
gcc --version查看实际版本；-std=gnu17需 GCC 5+，-std=c23需 GCC 12+ - 临时降级选项更稳妥：把
-std=gnu17改成-std=gnu11（GCC 4.7+ 就支持） - 升级 GCC 要谨慎：系统自带的
gcc（如 Ubuntu 的/usr/bin/gcc）被包管理器管控，直接覆盖易崩系统工具链；建议用update-alternatives或装到/opt并显式调用路径
warning: format '%s' expects argument of type 'char *', but argument has type 'int'
这类警告常被忽略，但开启 -Werror 后直接变错误。本质是 printf/scanf 类型与实参不匹配，运行时可能崩溃或输出乱码。
- 别靠猜：查
man 3 printf确认每个格式符对应的真实类型，%d对int，%ld对long，%zu对size_t - 结构体成员或指针解引用后类型易错：比如
printf("%s", &str[0])是对的，但printf("%s", str[0])就传了char而非char * - 宏定义可能隐藏类型转换：如果用了类似
#define LOG(fmt, ...) printf(fmt, ##__VA_ARGS__)，要确保传入的参数类型仍符合 fmt
真正难缠的不是报错本身，而是错误信息指向的位置和真实原因之间存在延迟——比如头文件里一个宏展开后才暴露出语法错误，而报错却显示在 .c 文件第 87 行。遇到反复不理解的错误，先用 gcc -E 看预处理后的结果，比死盯原代码高效得多。
