核心问题是dyld运行时找不到动态库而非库缺失，需用otool -L查依赖、otool -l | grep -A2 LC_RPATH确认rpath规则、DYLD_PRINT_LIBRARIES=1实测加载路径，三者一致才完成闭环验证。
macos 应用安装后出现启动失败、功能异常或报错“library not loaded”，核心问题通常不是库文件缺失，而是 dyld 在运行时找不到它——路径配置没对上。修复关键在于顺着加载链逐层验证，而不是盲目复制文件或改权限。
查清应用真正依赖哪些库
先定位可执行文件位置：
- 命令行工具用
which 软件名（如which curl）； - 图形应用路径一般是
/Applications/xxx.app/Contents/MacOS/xxx。
执行：otool -L /path/to/binary
输出中每行都是一个依赖项，重点关注带 @rpath/、@loader_path/ 或 @executable_path/ 的路径——这些是动态解析的，不是绝对路径。
确认 rpath 解析规则是否生效
@rpath 不是固定目录，得看二进制里嵌入的加载规则：
- 运行
otool -l /path/to/binary | grep -A2 LC_RPATH，找出所有生效的 rpath 条目，例如@executable_path/../Frameworks； - 多个 rpath 按顺序尝试，第一个匹配即停止，不继续往后找；
- 如果没输出
LC_RPATH，说明该程序根本不走 rpath，只认绝对路径或系统默认路径（/usr/lib、/System/Library/Frameworks）。
手动验证库文件是否存在且可访问
把 @rpath 替换成实际路径，去对应位置检查：
- 假设依赖
@rpath/libcurl.dylib，rpath 是@executable_path/../Frameworks； - 那么就去
binary 所在目录/../Frameworks/libcurl.dylib找； - App 示例：
/Applications/MyApp.app/Contents/MacOS/MyApp→ 查/Applications/MyApp.app/Contents/Frameworks/libcurl.dylib； - 用
ls -l看文件是否存在、权限是否为可读、软链接是否指向有效目标。
实测运行时真实加载行为
静态分析可能被环境变量或重定向干扰，最可靠的是让程序跑起来看 dyld 实际动作：
- 临时启用日志：
DYLD_PRINT_LIBRARIES=1 ./binary_name 2>&1 | grep libname； - 已启动的应用，用
lsof -p $(pgrep -f "binary_name") | grep dylib查当前加载路径； - 装
dyldinfo（brew install dyldinfo）后，运行dyldinfo -dylibs binary_name可看绑定细节。
只有 otool -L、LC_RPATH 和 DYLD_PRINT_LIBRARIES 三者结果一致，才能确认路径闭环无误。
