直接用 gcc 编译单个 c 文件不加选项会默认生成 a.out，易覆盖且难识别；必须用 -o 显式指定输出名，如 gcc main.c -o myapp，多文件编译时 -o 仅能出现一次且须在源文件列表之后。
直接用 gcc 编译单个 C 文件，不加任何选项，就能生成可执行文件——但这是最简形式，实际开发中几乎没人这么用，因为没法控制输出名、看不到警告、无法调试、也不能链接外部库。
怎么指定输出文件名（-o）
默认生成 a.out，既难识别又易覆盖。必须用 -o 显式命名：
-
gcc main.c -o myapp→ 生成可执行文件myapp -
gcc -o server server.c utils.c network.c→ 多文件一起编译并命名 - 如果漏写
-o且有多个源文件，GCC 会报错：gcc: fatal error: no input files（因它把第二个文件名误认为输出名）
如何分步控制编译流程（-E / -S / -c）
一键编译掩盖了问题定位能力。遇到宏展开异常、汇编逻辑可疑或符号未定义时，得停在某一步检查：
-
gcc -E hello.c > hello.i→ 查看预处理后是否正确包含头文件、宏是否被替换 -
gcc -S hello.c→ 生成hello.s，确认函数调用、寄存器使用是否符合预期 -
gcc -c module.c→ 只生成module.o，不链接；适合多文件项目中只重编修改过的模块 - 注意：
-c输出的目标文件名默认是xxx.o，不能和源文件同名（如gcc -c main.c -o main.c会覆盖源码）
为什么加 -Wall 和 -g 几乎是必选项
不加警告和调试信息，等于放弃基本工程保障：
-
gcc -Wall -g main.c -o main→ 启用常规警告 + 调试符号 -
-Wall会捕获未初始化变量、隐式函数声明、格式串不匹配等高频错误；-Wextra可进一步收紧（比如检测无用的 else 分支） -
-g不影响运行性能，但让gdb能显示源码行号、变量值；没有它，调试时只能看到汇编指令 - 线上发布前可去掉
-g减小体积，但开发阶段禁用-g是自断手脚
链接外部库时 -I、-L、-l 的顺序和常见坑
调用 libcurl 或自建静态库时，路径和名字必须严格匹配：
gcc main.c -I./include -L./lib -lcurl -o app-
-I后跟头文件目录（不是头文件路径），-L后跟库文件所在目录，-l后只写库名（如curl对应libcurl.so或libcurl.a） - 顺序不能颠倒：
-l必须放在源文件或目标文件之后，否则链接器找不到依赖符号（undefined reference to 'xxx'） - 若库名不标准（如
libmyutil_v2.a），不能用-lmyutil_v2，得直接写./lib/libmyutil_v2.a
真正容易被忽略的是：GCC 默认按系统 ABI 链接动态库，但如果你用了 -static 却没装对应静态库（如 libc.a），编译会直接失败，而不是回退到动态链接——这种错误不会报“找不到库”，而是报一堆符号未定义，排查起来特别绕。
