动态库问题主要分四类：找不到库（@rpath路径未匹配）、符号未定义（visibility隐藏或非dynamiclib）、ABI不兼容（Clang版本/STL跨dylib传递）、调试信息缺失（-g未生效或被strip）。
找不到动态库（dyld: Library not loaded）
这是最常见的情况，报错形如 dyld: Library not loaded: @rpath/libfoo.dylib 或 Reason: image not found。根本原因不是代码写错了，而是运行时链接器找不到那个 .dylib 文件。
排查优先看三件事：
- 用
otool -L查看程序依赖哪些库、路径写成什么形式（@rpath、@executable_path还是绝对路径） - 用
dyld_info -arch all -dylibs（macOS 13+）或objdump -p确认| grep LC_RPATH @rpath实际展开成哪些目录 - 确认目标
.dylib确实存在于某个@rpath路径下；如果没放对位置，别改代码，改install_name_tool -add_rpath或编译时加-rpath
符号未定义（Undefined symbols for architecture x86_64）
这类错误实际发生在链接阶段，但常被误认为“运行时报错”——因为你在运行前没做完整构建验证。Clang 默认启用 -dead_strip，若某函数只在动态库中定义、主程序又没显式调用，可能被裁掉导致运行时崩溃。
关键检查点：
- 确认你用的是
-dynamiclib编译的 dylib，而不是静态库（.a）或普通对象文件 - 确保导出符号存在：用
nm -m libfoo.dylib | grep -v "U "看有没有你期望的符号；若全是U（undefined），说明没真正实现或被__attribute__((visibility("hidden")))挡住了 - Clang 默认
-fvisibility=hidden，必须给要导出的函数/类加__attribute__((visibility("default")))，或者编译时加-fvisibility=default
ABI 不兼容导致 crash（EXC_BAD_ACCESS / segfault）
比如用 Clang 15 编译的 dylib，被 Clang 12 的主程序加载后一调用就崩。这不是语法问题，而是 C++ ABI（尤其是 STL 容器、异常、RTTI）在不同 Clang 版本间不保证二进制兼容。
务实做法：
- 尽量让主程序和 dylib 使用同一套 Clang + libc++ 版本；查版本用
clang++ --version和otool -l libfoo.dylib | grep -A2 LC_BUILD_VERSION - 避免跨 dylib 边界传递 STL 对象（
std::string、std::vector）；改用 C 风格接口（const char*、int*、回调函数指针） - 若必须传 C++ 对象，确保两边都链接
-stdlib=libc++，且 dylib 显式导出所有用到的模板实例化（用extern template控制）
调试时看不到符号（no debug info in dylib）
即使加了 -g，Clang 生成的 dylib 也可能在 lldb 里显示 symbol not found 或跳转不到源码——因为调试信息默认不随 dylib 一起安装，或被 strip 掉了。
确保调试可用：
- 编译 dylib 时明确加
-g -glldb（macOS 推荐），并避免后续strip或install_name_tool -strip - 运行前设置
export DYLD_DEBUG=0x80可看到 dyld 加载符号的过程；配合lldb ./myapp后执行image list确认 dylib 已加载且有符号表 - 如果 dylib 是从其他路径加载（比如
dlopen("/tmp/libfoo.dylib", RTLD_NOW)），需手动用add-dsym /tmp/libfoo.dylib告诉 lldb 加载调试信息
Clang 动态库的问题多数不在代码逻辑，而在构建配置与运行时环境的耦合细节。最容易被忽略的是 @rpath 解析顺序和 C++ ABI 的静默不兼容——它们不会报编译错误，却会在特定机器、特定版本上突然失效。
