头文件找不到时需用-I显式指定目录路径，-I后接头文件所在目录而非文件名，支持多路径叠加且顺序影响查找优先级，路径可为相对或绝对路径，含空格需加引号。
头文件找不到时，-I 参数必须显式指定路径
GCC 默认只在 /usr/include 和系统内置路径查头文件，项目自定义头文件（比如放在 ./include 或 ../common）不会自动识别。不加 -I 就会报错：fatal error: xxx.h: No such file or directory。
实操建议：
-
-I后面接的是「头文件所在目录」，不是头文件本身，例如头文件是./include/utils.h，应写-I./include - 可叠加多个
-I，顺序影响查找优先级：靠前的路径先被搜索，gcc -I./inc -I/usr/local/include main.c - 路径支持相对路径、绝对路径；若路径含空格，需用引号包裹：
-I"./my headers" - 不要把
-I放在命令末尾——GCC 对参数顺序敏感，库链接选项（如-lm）必须放在源文件之后，但-I可前置或后置，只要在对应源文件被处理前生效即可
多目录头文件共存时，避免重复包含和宏冲突
当项目同时引用系统头（如 "config.h"），且不同目录下存在同名头文件（比如两个 types.h），GCC 会按 -I 顺序和引号类型决定加载哪个。
关键区别：
- 用
-I路径，**不搜当前目录** - 用
"xxx.h"时，GCC **先搜当前目录**，再按-I顺序查找 - 若混用且路径未隔离，容易意外包含旧版头文件，导致编译通过但运行出错
- 推荐统一风格：项目内头文件全用
"xxx.h"，系统头用-I把各模块头目录分层隔离，例如：-I./core -I./drivers -I./platform
Makefile 中管理头文件路径更可靠
手动敲 gcc -I./inc -I./lib main.c utils.c -o app 容易漏写或路径写错，尤其在文件增删频繁时。直接硬编码路径还导致命令不可复用。
更稳妥的做法是提取为变量：
INC_DIRS = -I./include -I../shared/inc CFLAGS = -Wall -g $(INC_DIRS) app: main.o utils.o gcc $(CFLAGS) main.o utils.o -o app %.o: %.c gcc $(CFLAGS) -c $<p>这样改路径只需动 <code>INC_DIRS</code> 一行，所有编译步骤自动同步；且 <code>CFLAGS</code> 也顺带带上 <code>-Wall</code> 和 <code>-g</code> 等通用选项，不易遗漏。</p><h3>头文件依赖变化后，.o 文件可能 stale 导致静默错误</h3><p>当你修改了 <code>config.h</code> 但没重新编译依赖它的 <code>main.o</code>，GCC 不会自动检测这种头文件变更——它只看 <code>.c</code> 文件时间戳。结果是旧的 <code>main.o</code> 仍链接进新二进制，行为异常却无编译报错。</p><p>解决办法只有两个：</p>
- 每次改头文件后，手动删掉对应目标文件：
rm main.o再重编 - 用
gcc -M生成依赖规则（配合 Makefile），例如：gcc -MM main.c输出main.o: main.c config.h utils.h，让构建系统知道哪些 .o 需要重建 - 现代项目建议用
cmake或meson，它们默认处理头文件依赖，比手写 Makefile 更省心
这点特别容易被忽略：头文件改了但程序没重跑就上线，问题往往出现在最意想不到的地方。
