静态库在编译时链接，生成独立可执行文件，体积大但启动快、部署简单；动态库在运行时加载，节省空间且便于更新，但依赖外部文件、存在版本兼容风险；gcc默认优先链接.so，-static可强制静态链接，混合链接需用-wl,-bstatic/-bdynamic精确控制。
静态库和动态库根本不是“选哪个更好”，而是“在哪用、怎么部署”决定的——编译时嵌进去还是运行时加载，这一步选错，后面打包、发布、更新全要重来。
gcc链接时 -lmylib 到底找的是 .a 还是 .so？
默认情况下，gcc 优先链接动态库：-lmylib 会先找 libmylib.so，找不到才退而求其次找 libmylib.a。这不是配置问题，是 GCC 的硬编码行为。
- 想强制用静态库？加
-static：gcc main.c -L. -lmylib -static -o program - 只想对某一个库静态链接？用
-Wl,-Bstatic和-Wl,-Bdynamic控制范围：gcc main.c -L. -Wl,-Bstatic -lmylib -Wl,-Bdynamic -lc -o program - 如果同时存在
libmylib.a和libmylib.so，不加-static就一定走动态路径——哪怕你本意是离线部署
运行时报错 “error while loading shared libraries” 怎么快速定位？
这是动态库最典型的运行时失败，不是编译问题，而是加载器（loader）找不到 .so 文件。关键不在代码，而在路径和环境。
- 先查程序依赖了哪些库：
ldd ./program—— 看输出里有没有not found - 确认
.so文件是否存在且可读：ls -l libmylib.so；注意权限和路径是否匹配ldd输出里的路径 -
LD_LIBRARY_PATH只影响当前 shell 启动的进程，写进脚本也要export LD_LIBRARY_PATH=...:$LD_LIBRARY_PATH - 系统级部署别硬塞
LD_LIBRARY_PATH，改/etc/ld.so.conf.d/mylib.conf并运行sudo ldconfig
为什么静态库生成的可执行文件更大，但启动反而可能更快？
体积大是因为所有库代码都复制进去了，但这也意味着：没有运行时符号解析、没有 dlopen 开销、不依赖外部文件加载顺序——尤其在嵌入式或容器冷启动场景下，这点很实在。
- 静态链接后，
readelf -d program | grep NEEDED应该只显示libc.so等极少数系统库，没有你的libmylib.so - 动态库每次加载都要做重定位（relocation），尤其带
PIE或RELRO保护时，开销不可忽略 - 但代价是：改一行库代码，就得重新编译+分发整个可执行文件；而动态库只需替换
.so并确保 ABI 兼容
真正容易被忽略的点是：混合链接（部分静态、部分动态）时，-Wl,-Bstatic 的作用域必须紧邻目标库，漏掉一个 -Wl,-Bdynamic 就可能导致后续系统库也被强制静态链接——比如把 libm.a 塞进去，结果 libc.a 也进来了，最终链接失败或行为异常。
