正确做法是先用-gcc -c分别编译各源文件为.o，再链接；-I和-L路径须显式指定且顺序影响查找优先级；-g与-O2不可混用，调试用-O0，发布用-O2；-l库参数必须置于目标文件之后且按依赖顺序排列。
gcc 编译多文件时必须用 -c 分离编译
直接 gcc main.c utils.c -o app 看似省事，但一旦文件变多、依赖关系复杂，就容易因重复定义或符号冲突失败。真正健壮的做法是先分别生成目标文件，再统一链接。
-
gcc -c main.c -o main.o和gcc -c utils.c -o utils.o是标准起点，确保每个.c文件独立编译，不互相干扰 - 头文件路径必须显式传入：如果
utils.c包含#include "config.h"且该文件在./inc/下，就得加-I./inc到每条-c命令里 - 别省略
-o：不指定输出名时，gcc -c foo.c默认生成foo.o，但若多个源文件同名（比如不同目录下都有io.c），会相互覆盖
-I 和 -L 的顺序影响实际生效路径
-I 指定头文件搜索路径，-L 指定库搜索路径，但它们不是“加进去就行”，GCC 严格按命令行出现顺序查找——先命中者优先。
- 例如
gcc -I/usr/local/include -I./include main.c -L./lib -L/usr/lib -lcurl -o app：预处理时，./include里的curl.h会覆盖/usr/local/include中的同名头文件；链接时，./lib下的libcurl.a也会优先于系统/usr/lib中的动态库被选中 - 若项目同时用自定义头文件和第三方静态库，常见写法是
-I./hdr -L./lib -lmyutil，其中./lib/libmyutil.a必须真实存在，否则报错cannot find -lmyutil -
-I路径末尾不加斜杠不影响识别，但路径本身不能含空格；含空格需用引号包裹，如-I"/path/to my headers"
调试 + 警告 + 优化参数不能随意混搭
-g、-Wall、-O2 这三个最常用参数组合起来看似合理，但实际有隐含冲突：优化可能消除变量或重排逻辑，导致 -g 生成的调试信息与源码行为不一致。
- 开发阶段推荐
gcc -g -Wall -Wextra -O0：关掉优化，保证 gdb 断点准确停在对应行，警告全开但不中断编译 - 发布前构建用
gcc -O2 -Wall -Werror：启用二级优化，同时把所有警告当错误拦住，避免带隐患上线 -
-Werror很危险——某些旧代码在升级 GCC 后会因新增警告（如-Wstringop-overflow）直接编译失败，建议只在 CI 流水线中启用，本地开发保留-Wall -Wextra即可
链接阶段漏掉 -l 或顺序错会导致 undefined reference
报错信息如 undefined reference to 'pthread_create' 并不意味着没装 pthread 库，而是链接器没在正确时机看到它。
-
-l参数必须放在目标文件 之后：正确写法是gcc main.o utils.o -lpthread -o app；若写成gcc -lpthread main.o utils.o -o app，部分 GCC 版本会忽略该库 - 多个库之间有依赖顺序：比如用到了 OpenSSL 的 crypto 和 ssl 模块，就得写成
-lcrypto -lssl，反过来（-lssl -lcrypto）会失败，因为ssl依赖crypto中的符号 - 静态库
.a和动态库.so可共存，但-static会强制全静态链接，此时若系统缺少某个静态库（如libz.a），编译直接终止，而非退而求其次用动态版
-I 和 -L 的路径有效性验证——写进命令行不等于路径真存在，也不等于里面真有对应头文件或库文件。建议在执行前用 ls -l ./inc/config.h 和 ls -l ./lib/libxxx.a 手动确认，比等报错再排查快得多。 
