头文件不编译但必须被预处理器找到，否则报fatal error；#include "xxx.h"先查源文件所在目录再查-I和系统路径，#include 跳过当前目录只查-I和系统路径。
直接给结论：头文件本身不编译，但必须让预处理器能找到它；否则编译阶段就卡在 #include 上，报 fatal error: xxx.h: No such file or directory。
为什么 #include "xxx.h" 和 #include <xxx.h></xxx.h> 查找路径不同
这不是语法差异，是搜索顺序硬编码进 GCC 的行为："xxx.h" 优先查当前源文件所在目录（比如 src/main.c 包含 "util.h"，GCC 先去 src/ 找）；而 <xxx.h></xxx.h> 直接跳过当前目录，只按 -I 路径、系统默认路径（如 /usr/include）顺序搜索。
常见错误现象：
- 把自定义头文件放错位置（比如放在
include/下，却没加-I include） - 用
<myheader.h></myheader.h>写自定义头文件，结果 GCC 根本不去你项目目录里找 - 头文件里又
#include "xxx.h"，形成嵌套查找，路径链断裂
编译多文件 + 头文件项目的三步实操法
别一股脑 gcc main.c utils.c -o app —— 这样看似能过，但一旦头文件路径不对或依赖混乱，后续改一个 .c 就得全重编。正确做法分三步：
-
gcc -c -I ./inc -I ./src main.c -o obj/main.o（-c只生成目标文件，-I告诉预处理器去哪找头文件） -
gcc -c -I ./inc -I ./src utils.c -o obj/utils.o（每个.c独立编译，复用同一组-I） -
gcc obj/main.o obj/utils.o -o app（纯链接，不碰头文件）
注意：-I 必须出现在对应 gcc -c 命令里，不能只写在最后链接那步——因为头文件查找只发生在预处理阶段，链接时早结束了。
gcc -E 是查头文件路径问题的唯一可靠手段
当你不确定头文件到底从哪来的，或者怀疑宏定义被覆盖了，别猜，直接看预处理输出：
-
gcc -E -I ./inc main.c | grep "util.h"—— 看是否真包含了你预期的util.h -
gcc -E -dM -xc /dev/null | grep __linux__—— 检查内建宏是否符合目标平台 -
gcc -E -dl main.c—— 列出所有实际被包含的头文件路径，确认有没有漏掉-I或路径拼错
别依赖 ls 或眼睛扫目录结构，预处理器展开后的真实路径才是唯一事实。
容易被忽略的坑：头文件里的 #include 不继承父级 -I
假设 main.c 里写 #include "config.h"，而 config.h 里又写 #include "platform.h"。你只对 main.c 加了 -I ./cfg，但 platform.h 在 ./plat 下——这不行。预处理器不会“记住”上一层的 -I，每个 #include 都重新走一遍搜索路径。所以必须：
- 要么把所有头文件统一放到一个目录，用一个
-I覆盖 - 要么显式叠加多个
-I：gcc -c -I ./cfg -I ./plat main.c - 要么在
config.h里用相对路径写#include "../plat/platform.h"（不推荐，路径脆弱）
最稳的方式，是让所有 #include 都基于项目根目录写，然后用多个 -I 把各头文件目录都挂进去——这样不管谁包含谁，路径都通。
