-fsyntax-only仅做语法检查，不生成文件，但需预处理成功；-c生成目标文件以支持增量构建；默认编译隐含风险，推荐-Wall -g -o组合；链接时-l必须置于目标文件之后且配合-L指定路径。
gcc 编译 C 文件不是“一条命令走天下”，而是按需组合不同阶段选项。核心在于理解每个选项触发哪一阶段，以及是否生成中间产物。
只做语法检查：用 -fsyntax-only
不生成任何输出文件，只报错或警告，适合快速验证代码能否过编译前端。
常见误用：把它当“轻量编译”来用，其实它跳过了预处理（比如 #include 路径错误、宏展开失败都检测不到）。
正确用法：gcc -fsyntax-only main.c
注意：若头文件路径不对，-fsyntax-only 仍会报 fatal error: xxx.h: No such file or directory —— 因为预处理是语法检查的前提。
分步生成目标文件：必须加 -c
这是多文件项目最常踩坑的点：gcc foo.c bar.c -o prog 看似简洁，但每次都会重编所有源文件；而 -c 能分离编译与链接，实现增量构建。
关键规则：
• gcc -c foo.c 生成 foo.o，不链接，也不依赖其他 .c 文件
• gcc -c foo.c -o build/foo.o 可指定输出路径，避免污染源码目录
• 若漏掉 -c 直接写 gcc foo.c bar.c，GCC 会尝试直接链接——此时若 bar.c 里有未定义符号，错误信息指向链接阶段，反而掩盖了真正的源码问题
生成可执行文件：默认行为但隐含风险
直接运行 gcc main.c 会走完全部四阶段（预处理 → 编译 → 汇编 → 链接），输出 a.out。
但实际开发中几乎不用这个默认：
• 没有 -o 时，Windows 下可能生成 a.exe，Linux/macOS 是 a.out，跨平台脚本易出错
• 不加 -Wall 会忽略潜在 bug，比如未初始化变量、隐式函数声明
• 缺少 -g 导致后续无法用 gdb 调试，且调试信息无法被剥离（strip 前必须先带 -g 编译）
推荐最小安全组合：gcc -Wall -g -o myapp main.c
链接外部库时 -l 和 -L 的顺序不能颠倒
gcc main.o -lm -o app 是对的；gcc -lm main.o -o app 在某些旧版 GCC 上可能失败。
原因：链接器从左到右扫描参数，遇到 -lxxx 时，只查找它**右侧已知的目标文件或库**。
所以正确模式是：
• 先列目标文件（.o）
• 再用 -L/path/to/lib 告诉链接器去哪里找库
• 最后用 -lxxx 指定要链接的库名（如 -lm 对应 libm.so 或 libm.a）
如果库在非标准路径（比如 ./libs），必须写成：gcc main.o -L./libs -lmyutil -o app，缺一不可。
-c 生成的 .o 文件不包含调试信息（除非你显式加 -g），而链接阶段的 -g 无效——调试信息必须在编译阶段注入。 
