c_include_path起作用，但仅在系统默认路径之前被搜索且需前置拼接；对#include 默认不生效，须配合-nostdinc或改用-i才可靠。
gcc找不到头文件时，C_INCLUDE_PATH到底起不起作用
不起作用是常态，不是配置错了，而是你没关掉默认路径干扰。GCC在启用 C_INCLUDE_PATH 前，会先查 -I 指定路径，再查环境变量，最后才查系统默认路径（如 /usr/include）。但关键点在于：如果头文件恰好也在默认路径里存在同名文件，GCC可能直接用错的那个——你加的路径根本没被“轮到”。
验证方式很简单：gcc -v -E dummy.c 2>&1 | grep "search starts here"，输出里会列出完整搜索顺序。你加的 C_INCLUDE_PATH 值只有出现在这个列表靠前位置，才算真正生效。
- 必须用
export C_INCLUDE_PATH=/your/path:$C_INCLUDE_PATH，前置拼接，不能后置 - Windows 下对应的是
CPLUS_INCLUDE_PATH（MSYS2/MinGW）或直接用include环境变量（某些旧版 GCC） - 修改后要新开终端或执行
source ~/.bashrc，echo $C_INCLUDE_PATH能看到值才算落地
为什么设置了C_INCLUDE_PATH，#include 还是报错
因为 #include <xxx.h></xxx.h> 默认只走系统路径和 -I，不自动触发 C_INCLUDE_PATH ——除非你显式禁用默认路径。GCC 的设计逻辑是：环境变量只是“补充”，不是“替代”。想让 C_INCLUDE_PATH 对 生效，得加 -nostdinc：
gcc -nostdinc -I /your/path main.c
但这样会连 stdio.h 都找不到，所以更稳妥的做法是保留默认路径，只用 -I 显式覆盖：
访问全球海洋潮汐模型。功能包括查询指定日期、时间和地点的潮高、潮汐极值及格点天气数据。
-
gcc -I /your/path -I /usr/include main.c（手动补全系统路径） - 或者把你的路径软链进
/usr/local/include，一劳永逸 - 避免混用
C_INCLUDE_PATH和-I处理同一类头文件，容易路径重复、优先级混乱
跨平台项目中C_INCLUDE_PATH和CPLUS_INCLUDE_PATH怎么分
C 代码用 C_INCLUDE_PATH，C++ 代码用 CPLUS_INCLUDE_PATH，两者互不继承。如果你混写（比如 .cpp 文件里 include C 头），GCC 实际调用的是 C++ 前端，此时只读 CPLUS_INCLUDE_PATH。常见翻车点：
- 用
g++编译纯 C 文件，结果C_INCLUDE_PATH完全被忽略 - 头文件里用了
extern "C"包裹，但路径仍按 C++ 规则查，得确保路径在CPLUS_INCLUDE_PATH里 - 交叉编译时，工具链自带的
sysroot路径优先级高于所有环境变量，CPLUS_INCLUDE_PATH可能被静默跳过
动态库头文件路径和运行时库路径容易搞混
头文件路径（C_INCLUDE_PATH）只影响编译阶段，跟 LD_LIBRARY_PATH 或 /etc/ld.so.conf 完全无关。有人配好了头文件路径，却在运行时报 libxxx.so: cannot open shared object file，这是典型混淆。
记住三件事：
- 编译时找头文件 →
-I或C_INCLUDE_PATH - 链接时找
.a/.so→-L或LIBRARY_PATH - 运行时找
.so→LD_LIBRARY_PATH或/etc/ld.so.cache
最常漏的是：改了 C_INCLUDE_PATH 后，忘了同步更新 LIBRARY_PATH，导致头文件能包含，但链接失败，报 undefined reference to xxx。
