-L参数仅影响链接阶段，用于指定库文件搜索路径，与头文件路径无关；-I只作用于预处理阶段找头文件，-rpath或LD_LIBRARY_PATH才控制运行时动态库加载。
-L 参数只影响链接阶段，不是加头文件路径
很多人一看到“找不到库”就下意识加 -I，结果编译通过、链接失败，报 undefined reference to。因为 -I 只告诉预处理器去哪找 #include 的头文件，跟链接器找 .a 或 .so 完全无关。真正让链接器知道库在哪的，是 -L。
用法很简单：g++ main.cpp -L/path/to/your/libs -lmylib -o app。注意三点：
-
-L必须写在对应-l之前，顺序错（比如-lmylib -L/path）就无效 -
-L不递归子目录，-L./lib不会自动扫./lib/utils/ - 多个目录要重复写
-L，例如-L./deps -L/usr/local/lib，链接器从左到右匹配，找到第一个libmylib.a就停
链接静态库时，-l 名字怎么对应真实文件名
-lmyutil 不是直接找 myutil.a，而是按固定规则搜索：libmyutil.a → libmyutil.so（如果启用了动态链接）。所以你的库必须叫 libxxx.a 或 libxxx.so 才能被 -lxxx 命中。
立即学习“C++免费学习笔记（深入）”；
常见例外情况：
- 库名含特殊字符（如
libmy_util.a），仍用-lmy_util，clang/gcc 都会自动补前缀和后缀 - 库文件名不标准（如
foo_static.lib或zstd.a），-l失效，只能写绝对/相对路径：g++ main.cpp ./zstd.a -o app - 想强制静态链接（跳过同名
.so），用-Wl,-Bstatic -lzstd -Wl,-Bdynamic
程序运行时报 “error while loading shared libraries” 怎么办
-L 只管编译期链接，不管运行时加载。运行时报这个错，说明动态链接器（ld-linux.so）根本没在它的搜索路径里找到 .so 文件。
临时解决：运行前设环境变量LD_LIBRARY_PATH=/path/to/libs:$LD_LIBRARY_PATH ./app
长期方案：编译时嵌入运行时搜索路径，用 -Wl,-rpath,/path/to/libs。注意：
- Linux 下有效；macOS 上
-rpath默认不写入二进制，得加-Wl,-rpath,/path并确认otool -l ./app | grep -A2 LC_RPATH有输出 - 支持
$ORIGIN（表示可执行文件所在目录），例如-Wl,-rpath,'$ORIGIN/../lib'，单引号防 shell 展开 - macOS 还要检查 dylib 的 install name 是否匹配，不匹配得用
install_name_tool -id "@rpath/libxxx.dylib" libxxx.dylib
最易被忽略的一点：路径指定是分阶段的——-I 是预处理阶段，-L 是链接阶段，-rpath 或 LD_LIBRARY_PATH 是运行阶段。三个阶段互不感知，不能靠一个参数打遍天下。
