-I路径插入系统默认搜索路径最前面，多个-I按命令行从左到右顺序查找，必须置于源文件前；#include""先查当前目录再-I路径，则跳过当前目录直接查-I路径。
g++ 的 -I 选项到底加在哪儿？位置很关键
顺序决定头文件查找优先级：-I 路径会插入到系统默认头文件搜索路径的**最前面**，但多个 -I 之间按命令行出现顺序从左到右依次查找。如果两个目录里有同名头文件，左边的 -I 目录里的会被优先选中。
必须放在源文件或 -o 之前，否则 g++ 会报错或忽略：
g++ -I./include -I/usr/local/mylib/include main.cpp -o main # ✅ 正确
g++ main.cpp -I./include -o main # ❌ -I 被当作 main.cpp 的参数，无效
- 多个
-I可叠加，没有数量限制 - 路径支持相对路径（如
-I../deps/include）和绝对路径（如-I/opt/boost/include） - 路径末尾的斜杠可加可不加，
-I./include和-I./include/效果一样
为什么 #include "xxx.h" 和 #include <xxx.h></xxx.h> 对 -I 敏感度不同？
#include "xxx.h" 会先在当前源文件所在目录找，再依次检查所有 -I 路径（从左到右），最后才查系统路径；而 #include <xxx.h></xxx.h> **跳过当前目录，直接从 -I 路径开始找**，再查系统路径。
这意味着：如果你用 #include <mylib></mylib>，就必须靠 -I 指向包含 mylib/config.h 的父目录，比如：
立即学习“C++免费学习笔记（深入）”；
project/ ├── src/main.cpp └── deps/include/mylib/config.h
此时要编译，得写：g++ -Ideps/include src/main.cpp —— 注意是 deps/include，不是 deps/include/mylib。
- 误写成
-Ideps/include/mylib会导致#include <mylib></mylib>找不到，因为预处理器会在deps/include/mylib/mylib/config.h下找 - 想统一用双引号风格又不想改 include 写法？可以加
-iquote，它只影响双引号查找，不干扰尖括号
常见错误：路径存在空格、中文或软链接没处理好
空格和中文路径必须用引号包裹，否则 shell 会截断：
g++ -I"../third party/include" -I"/Users/张三/SDK/inc" main.cpp # ✅
g++ -I../third party/include main.cpp # ❌ 变成两个参数：-I../third 和 party/include
软链接目录本身没问题，但要注意 g++ 实际展开的是链接目标路径；如果目标路径权限不足或跨文件系统，可能触发 fatal error: xxx.h: No such file or directory。
- 用
ls -l确认软链接指向真实可读目录 - 避免在
-I中混用符号链接和绝对路径，容易在不同机器上行为不一致 - CI 环境中建议用
readlink -f展开为绝对路径再传给-I，增强可复现性
替代方案：用 -isystem 或环境变量 CPLUS_INCLUDE_PATH 吗？
-isystem 和 -I 功能相似，但关键区别是：它把路径加入“系统头文件”搜索链，导致该路径下的头文件**不会触发 GCC 的警告（比如 -Wall 下的未声明函数警告）**，常用于第三方库头文件隔离。一般项目自定义头文件别用它。
CPLUS_INCLUDE_PATH 环境变量能代替部分 -I，但它是全局生效的，容易污染构建过程，且无法控制顺序——所有值拼接后统一插在系统路径前，无法像 -I 那样精细排序。CI 脚本里偶尔用，日常开发强烈建议坚持显式 -I。
-
-I是最直接、最可控、最符合人直觉的方式 - Makefile 里写
CXXFLAGS += -I$(DEPS_INC)比用环境变量更清晰可靠 - 如果项目头文件层级深（如
core/utils/string_view.h），与其堆砌多个-I，不如统一用一个根路径 + 规范 include 路径
实际项目里最容易被忽略的是 -I 路径与 #include 写法之间的映射关系——不是“路径对”，而是“路径前缀对”。多一层目录嵌套，就多一分出错可能。
