结论是头文件未丢失，而是gcc未获知搜索路径或对应开发包未安装；基础头文件缺失需安装build-essential（debian系）或“development tools”（rhel系），第三方头文件需装-dev/-devel包，自定义路径必须用-i显式指定。
直接说结论：不是头文件丢了，而是GCC根本没去它该去的地方找。绝大多数情况，fatal error: xxx.h: No such file or directory 错误跟“文件不存在”无关，只跟“路径没告诉GCC”或“开发包压根没装”有关。
查不到 stdio.h 这种基础头文件？先装开发包
如果连 stdio.h、stdlib.h 都报错，说明系统级C标准库头文件缺失——这不是路径问题，是开发环境没搭好。
- Ubuntu/Debian 系统执行：
sudo apt update && sudo apt install build-essential - CentOS/RHEL 8+ 执行：
sudo dnf groupinstall "Development Tools" - CentOS/RHEL 7 执行：
sudo yum groupinstall "Development Tools"
注意：build-essential（Debian系）和 "Development Tools"（RHEL系）是元包，会自动拉取 gcc、glibc-devel、kernel-headers 等必需组件。不装它们，/usr/include 下连 sys/cdefs.h 都没有。
openssl/ssl.h 或 libavcodec/avcodec.h 找不到？装对应 -dev/-devel 包
第三方库的头文件从不随主程序一起安装。比如你 yum install ffmpeg，但头文件在 ffmpeg-devel；apt install openssl 不提供 openssl/ssl.h，得装 libssl-dev。
- Debian/Ubuntu 常见对应关系：
libcurl4-openssl-dev→curl/curl.h，libpng-dev→png.h - RHEL/CentOS：
openssl-devel、ffmpeg-devel、libpng-devel - 装完后头文件通常落在
/usr/include/或/usr/include/xxx/子目录下，不是随便放的
别用 find / -name "ssl.h" 2>/dev/null 盲搜——先确认包名再装，比硬找靠谱十倍。
头文件在 /opt/mylib/include，但 #include <mylib.h></mylib.h> 还是报错？用 -I 显式指定
#include 不会自动扫你自定义路径。GCC 搜索顺序固定：-I 路径 → 环境变量 → 默认路径（/usr/include 等）。跳过 -I 就等于没告诉它去哪儿找。
- 正确写法：
gcc -I/opt/mylib/include main.c -L/opt/mylib/lib -lmylib - 多个路径可叠加：
gcc -I./inc -I/usr/local/include -I/opt/thirdparty/include main.c - 路径用相对或绝对均可，但别漏掉
-I前面的空格，也别写成-i（小写 i 是错的） - Makefile 里加到
CFLAGS：CFLAGS += -I/opt/mylib/include
别改 #include <mylib.h></mylib.h> 成 #include "inc/mylib.h" ——那是给 #include "" 用的，且只查当前目录，不解决系统级包含问题。
为什么 gcc -v -E -x c /dev/null 2>&1 | grep "search starts here" 输出里没看到你要的路径？
这个命令输出的是 GCC 实际生效的头文件搜索路径列表。如果里面没有你期望的路径，说明 -I 没传进去、环境变量没生效，或者你用了 -nostdinc 却没补全所有路径。
-
CPATH和C_INCLUDE_PATH是环境变量，需export后生效，且只对当前 shell 有效 -
-I优先级永远高于环境变量，别指望靠设C_INCLUDE_PATH替代-I - 交叉编译或
-m32场景下，GCC 会切到/usr/include/i386-linux-gnu/这类架构专属路径，此时要装gcc-multilib或libc6-dev-i386
最稳妥的做法永远是：明确用 -I 把路径写进编译命令，而不是依赖环境或猜测默认行为。
