-i参数必须紧接路径无空格，否则编译器误将路径当作源文件；支持绝对或相对路径，多-i按顺序搜索；#include仅查-i和系统路径，#include""优先查源文件所在目录；环境变量c_include_path（c）和cplus_include_path（c++）可替代-i。
gcc -I 后面不能加空格
写成 gcc -I /path/to/include 是错的，编译器会把 /path/to/include 当作要编译的源文件，报 no such file or directory。正确写法是 gcc -I/path/to/include（-I 和路径之间**紧挨着、无空格**），这是 GCC 的硬性语法要求。
常见错误现象：gcc: error: /path/to/include: No such file or directory，本质就是空格导致参数解析失败。
- 路径可以是绝对路径（如
-I/home/user/mylib/include）或相对路径（如-I../deps/include） - 多个
-I参数按出现顺序搜索，先命中者优先，比如gcc -I./inc -I/usr/local/include main.c会先查当前目录下的inc/ - 如果头文件在子目录里（如
mylib/config.h），#include <mylib></mylib>才能被-I./inc匹配到，不能写成#include "config.h"然后指望它自动进子目录找
尖括号 和双引号 "" 的行为差异直接影响 -I 是否生效
#include <xxx.h></xxx.h> 只走 -I 指定路径 + 系统路径；而 #include "xxx.h" 默认先查当前源文件所在目录，再查 -I 路径，最后才查系统路径。所以如果你用了 -I 却仍报错，先确认 include 写法是否匹配。
- 用
#include <myheader.h></myheader.h>→ 必须靠-I或环境变量才能找到，不查当前目录 - 用
#include "myheader.h"→ 默认先查main.c所在目录，即使没写-I也可能成功，容易掩盖路径配置问题 - 工程中混用两种写法时，
-I对生效，对""是“锦上添花”，不是“雪中送炭”
C 和 C++ 要用不同的环境变量控制默认头文件路径
如果不想每次编译都敲 -I，可以用环境变量，但必须分清语言：C 用 C_INCLUDE_PATH，C++ 用 CPLUS_INCLUDE_PATH，两者互不影响。设错变量名（比如给 C++ 项目只设 C_INCLUDE_PATH）会导致 -I 以外的路径完全不生效。
- 临时设置：
CPLUS_INCLUDE_PATH=/opt/mycpp/include:$CPLUS_INCLUDE_PATH gcc -c main.cpp - 永久设置可写入
~/.bashrc，但要注意路径分隔符是冒号（:），不是分号 -
CPATH是通用变量，对 C/C++/ObjC 都生效，但优先级低于语言专用变量，慎用以免覆盖预期行为
验证 -I 是否真的起作用，别只看编译过没过
编译通过不代表头文件来自你指定的路径——可能只是碰巧系统路径里也有同名文件。最稳妥的方法是用 gcc -E -v main.c 查看预处理阶段的完整搜索路径和实际包含的文件绝对路径。
-
gcc -E main.c | head -20可快速看到预处理输出里实际展开的是哪个stdio.h -
gcc -v -E main.c 2>&1 | grep "search starts here"直接定位搜索路径顺序 - 若发现本该命中
-I路径却 fallback 到/usr/include，大概率是路径拼写错误、权限不足，或头文件名大小写不一致（Linux 区分大小写）
./third_party/openssl/ssl.h，就得写 -I./third_party/openssl，然后代码里写 #include <ssl.h></ssl.h>，而不是 -I./third_party 加 #include <openssl></openssl> —— 后者只有当 openssl/ 是 -I 路径下的子目录时才成立。这个层级关系一旦错位，调试起来非常隐蔽。
