最简命令gcc source.c不适用于实际项目，应使用gcc -Wall -g -O0 -o output source.c；多文件需先-c生成目标文件再链接；链接时注意库顺序和-l选项。
最简命令是 gcc source.c，但实际项目中几乎不会直接用它——它隐式完成全部四阶段且不控制输出名、不启用警告、不带调试信息，容易掩盖问题。
直接生成可执行文件（单文件）
适用于快速验证小片段，但必须加 -o 指定名字，否则默认输出 a.out，极易覆盖或混淆：
-
gcc hello.c -o hello：生成可执行文件hello，推荐作为最小可行命令 - 不加
-o时，gcc hello.c确实能跑通，但下次编译另一个test.c会再次覆盖a.out，调试时根本分不清是谁的产物 - 如果源文件用了非标准头文件（比如自定义
utils.h），必须加-I，否则报错fatal error: utils.h: No such file or directory
多文件项目必须分步：先 -c 再链接
多个 .c 文件不能靠一条 gcc a.c b.c -o app 硬凑——它虽能工作，但每次修改任一文件都会重编所有源码，浪费时间。正确做法是分离编译与链接：
-
gcc -c main.c -o main.o和gcc -c utils.c -o utils.o：各自生成目标文件，互不影响 -
gcc main.o utils.o -o app：只做链接，快且稳定 - 漏掉某个
.o（比如忘了utils.o）会导致链接错误undefined reference to 'xxx'，不是编译错误，容易排查走偏 - 若函数在
utils.c中定义但没被main.c声明，-Wall会在编译main.c时就报implicit declaration，比等到链接时报错更早暴露问题
必须加的实用选项组合
裸用 gcc 编译等于放弃基本工程保障。以下三个选项应视为“起步标配”：
-
-Wall：开启常规警告，比如未初始化变量、类型不匹配、printf格式串与参数不符——这些在运行时才暴露，极难 debug -
-g：生成调试信息，否则gdb连函数名和行号都看不到，只剩汇编指令 -
-O0：关闭优化，避免编译器把变量优化掉或重排逻辑，让调试行为与源码严格对应 - 组合写法：
gcc -Wall -g -O0 main.c -o main；调试完再换-O2发布
容易被忽略的链接陷阱
生成可执行文件最后一步是链接，这里出错不报“编译失败”，而是报一堆 undefined reference，新手常误以为是函数写错了：
- 调用
sqrt()却没加-lm，链接时报undefined reference to 'sqrt'——数学库不默认链接 - 用
pthread_create()忘了-lpthread，同样报 undefined，且错误信息里不会提示缺哪个库 -
-lxxx的顺序有影响：gcc main.o -lm可以，但gcc -lm main.o在某些旧版 GCC 上可能失效（依赖关系需从左到右满足） - 静态库
libxxx.a和动态库libxxx.so同时存在时，gcc默认选动态库；加-static才强制静态链接，但需确保系统装了*-static包（如glibc-static）
真正麻烦的从来不是“能不能生成”，而是“生成的东西能不能可靠调试、能不能正确链接、改一行代码要不要等十秒”。把 -c 拆开、把 -Wall -g -O0 当成呼吸般自然，比记住一百个冷门选项更重要。
