gcc不递归扫描子目录，编译多目录项目必须用-i指定所有头文件根路径（如-i include -i include/core），-l和-l配合指定库路径与名称（如-l lib -lutils），且-i/-l顺序影响查找优先级，-o须置于命令末尾。
直接用gcc编译多目录源文件会报错
gcc 默认不递归扫描子目录，gcc src/*.c 只能匹配当前目录下的 .c 文件，src/utils/ 里的文件不会被包含。如果你硬写 gcc src/main.c src/utils/log.c src/core/init.c，看似可行，但实际容易出错：路径写错、漏文件、头文件找不到（#include "utils/log.h" 在 main.c 里能过，但 gcc 编译 log.c 时默认只搜当前目录和系统路径，找不到 utils/log.h）。
根本原因不是“命令写不对”，而是 gcc 本身不处理目录结构——它只管你给它的文件路径和 -I 路径是否能覆盖所有 #include。
必须用 -I 指定所有头文件根目录
假设项目结构是：
project/ ├── src/ │ ├── main.c │ └── core/ │ └── init.c ├── include/ │ ├── core/ │ │ └── init.h │ └── common.h └── lib/
main.c 里写了 #include "core/init.h"，init.c 里写了 #include "common.h"。这时编译命令必须带两个 -I：
-
-I include：让#include "common.h"能被找到 -
-I include/core：让#include "init.h"（实际是include/core/init.h）能被找到
完整命令示例：
gcc -I include -I include/core src/main.c src/core/init.c -o bin/app
注意：-I 的顺序有影响——gcc 从左到右查找头文件，如果两个路径下有同名头文件，左边的优先。别写成 -I include/core -I include，否则 common.h 可能被误覆盖。
目标文件分散在多目录时，-o 必须放在最后
如果你先生成 .o 文件再链接（推荐用于大项目），要注意 -o 的位置：
-
gcc -c src/main.c -o obj/main.o✅ 正确：每个-c命令单独配一个-o -
gcc -c src/main.c src/core/init.c -o obj/❌ 错误：gcc 不支持把多个.c编译结果一起输出到目录 -
gcc obj/main.o obj/core/init.o -o bin/app✅ 正确：链接阶段-o放最后，指定最终可执行文件名
常见错误是把 -o 写在中间，比如 gcc -c src/main.c -o obj/main.o src/core/init.c，这会导致 gcc 把 src/core/init.c 当作要链接的目标文件，报错 cannot execute binary file 或 file not recognized。
静态库跨目录链接时，-L 和 -l 不能省
假如你在 lib/ 下放了 libutils.a，而 main.c 用了里面定义的 log_init()：
-
-L lib：告诉链接器去lib/目录里找库文件 -
-lutils：表示链接libutils.a（自动补前缀lib和后缀.a） - 顺序不能颠倒：
gcc src/main.c -L lib -lutils -o bin/app✅；gcc src/main.c -lutils -L lib -o bin/app❌（部分旧版 gcc 会忽略）
如果库文件路径写成绝对或相对完整路径（如 lib/libutils.a），就不用 -L 和 -l，直接写在命令末尾：gcc src/main.c lib/libutils.a -o bin/app。但这种方式不便于移植，也不支持同名不同版本库切换。
真正麻烦的从来不是命令怎么敲，而是头文件路径和库路径的映射关系没理清——一旦 #include 路径和 -I/-L 不对齐，错误信息里根本不会告诉你缺哪个路径，只会报 fatal error: xxx.h: No such file or directory 或 undefined reference to 'xxx'，得自己一一对。
