修复macos dylib启动失败需闭环验证：先用otool -l查依赖路径，再用otool -l | grep lc_rpath确认rpath解析规则，最后用dyld_print_libraries=1实测运行时加载路径，三者一致则库可被正确找到。
macOS 软件安装后出现启动失败、报错“Library not loaded”或功能异常，十有八九是动态链接库（dylib）路径没对上。这不是软件装错了，而是系统在运行时找不到它依赖的库——关键不在于“有没有”，而在于“能不能被 dyld 找到”。检查路径不能只看文件存不存在，得顺着程序的加载逻辑一层层查。
先定位主程序，再查它真正依赖谁
别急着翻 /usr/local/lib 或 /opt/homebrew/lib，先锁定出问题的可执行文件在哪：
- 用
which 软件名（如which curl）看命令对应哪个二进制； - 如果是 App，路径通常是
/Applications/xxx.app/Contents/MacOS/xxx； - 确认路径后，立刻执行：
otool -L /path/to/binary
输出里每行都带一个路径，比如@rpath/libssl.3.dylib或/usr/lib/libz.dylib——这些就是它编译时“认”的库位置。
看清楚 @rpath 是怎么展开的
@rpath 不是真实路径，它要靠二进制里记录的 LC_RPATH 加载规则来解析。光看 otool -L 不够，还得查：
-
otool -l /path/to/binary | grep -A2 LC_RPATH—— 找出所有实际生效的 rpath，例如：@executable_path/../Frameworks或@loader_path/lib； - 注意：多个 rpath 会按顺序尝试，第一个命中即止；
- 如果输出为空，说明程序完全不走 @rpath，只认绝对路径或系统默认路径（
/usr/lib、/System/Library/Frameworks等）。
验证库文件是否真在搜索路径下
把 @rpath 替换成实际路径，手动检查文件是否存在：
- 假设
otool -L显示依赖@rpath/libcurl.dylib，且LC_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 yourlib（替换yourlib为库名关键词）； - 若程序已启动，用
lsof -p $(pgrep -f "binary_name") | grep dylib查当前加载的库路径； - 配合
dyld_info -dylibs binary_name（需提前brew install dyldinfo）可看到更细粒度的绑定与重定位信息。
路径检查不是一次性的动作，而是从声明（otool）、到解析（rpath）、再到加载（DYLD_PRINT_LIBRARIES）的闭环验证。只要三者对得上，dylib 就不会丢。
