编译时需用 -I 指定头文件搜索路径（指向 .h 所在直接父目录），链接时用 -L 指定库路径、-lxxx 指定库名（不带 lib 和后缀）；CMake 中应优先使用 find_package + target_link_libraries(... Boost::filesystem) 自动处理依赖，而非手动拼接 -I/-L/-l。
怎么让 #include 找到第三方头文件
编译器默认只在系统路径和当前源码目录下找头文件，第三方库的头文件不在其中，#include "xxx.h" 或 #include <xxx.h></xxx.h> 就会报错：fatal error: xxx.h: No such file or directory。
核心是告诉编译器“去哪找”——不是改代码里的路径，而是通过编译选项传路径：
- 用
-I/path/to/headers（GCC/Clang）或/I"path\to\headers"（MSVC）添加头文件搜索路径 - 路径必须指向存放
.h文件的**直接父目录**，比如库头文件在/usr/local/include/boost/filesystem.hpp，就加-I/usr/local/include，不是-I/usr/local/include/boost - 多个路径用多个
-I，顺序重要：靠前的路径优先匹配，避免意外覆盖系统头文件 - 如果头文件里又
#include <boost></boost>这种带子目录的写法，确保-I指向的是boost的上一级（即包含boost/目录的那一层）
链接时找不到 libxxx.a 或 libxxx.so
头文件找到了，但编译通过、链接失败，典型错误：undefined reference to 'xxx_function'。这说明符号定义在库文件里，但链接器根本没看到它。
分两步解决：
立即学习“C++免费学习笔记（深入）”；
- 用
-L/path/to/libs告诉链接器“去哪找库文件”，路径要精确到含libxxx.a或libxxx.so的目录 - 用
-lxxx告诉链接器“要链接哪个库”——注意：-lxxx会自动展开为查找libxxx.a（静态）或libxxx.so（动态），不需要写全名，也不能带lib前缀和后缀 -
-L和-l的顺序有影响：-L必须出现在对应-l之前，否则链接器还没知道去哪找，就先要连了 - 静态库（
.a）和动态库（.so/.dll）不能混用同一套参数逻辑；Windows 下 MSVC 用/LIBPATH和xxx.lib显式指定，不支持-l
CMake 中怎么正确配置 find_package 和 target_link_libraries
手写 -I 和 -l 容易出错且难维护，CMake 是更可靠的方案，但常见误区是把 find_package(XXX) 当万能钥匙——它不一定返回可用的头路径和库目标。
关键看 CMake 模块是否真正导出 INTERFACE_INCLUDE_DIRECTORIES 和 IMPORTED 目标：
- 优先用
find_package(Boost REQUIRED COMPONENTS filesystem system)，再用target_include_directories(myapp PRIVATE Boost::filesystem)，而不是自己拼include_directories(...) -
target_link_libraries(myapp PRIVATE Boost::filesystem)—— 这样才能自动带入头路径、编译定义、甚至依赖的其他库（如Boost::system） - 如果
find_package找不到，检查CMAKE_PREFIX_PATH是否包含库的安装根目录（比如/usr/local或你自定义的install/路径），或者手动指定find_package(XXX PATHS /opt/mylib) - 别在
target_link_libraries里混写-lxxx和 CMake 目标，CMake 会忽略纯字符串形式的链接项，导致静默失效
为什么 LD_LIBRARY_PATH 或 PATH 不解决编译期问题
很多人配完头文件和库路径还报错，转头去改 LD_LIBRARY_PATH（Linux）或 PATH（Windows），这是方向错了。
这两个环境变量只影响**程序运行时**动态库的加载，跟编译、预处理、链接完全无关：
-
LD_LIBRARY_PATH影响./a.out启动时找libxxx.so，不影响g++ main.cpp -lxxx链接阶段 - Windows 上
PATH影响a.exe运行时找xxx.dll，但编译时仍需/LIBPATH和xxx.lib - 真正卡在编译/链接阶段，99% 是
-I、-L、-l或 CMakefind_package配置不到位，不是运行环境问题 - 动态库版本冲突、RPATH 缺失这类问题，是部署阶段的事，别提前往环境变量里堆路径
路径配置这事，编译期和运行期像两条平行线，交叉点只在极少数构建脚本里，日常开发别指望它们互相救场。
