要定位mac应用崩溃根源，需用otool -l查主可执行文件依赖，路径必须为/applications/微信.app/contents/macos/wechat；再用otool -l | grep -a2 -b2 lc_rpath确认rpath是否有效；最后递归扫描所有非系统dylib依赖，修正硬编码路径。
想快速定位某个Mac应用崩溃或启动失败的根源，必须先看清它背后依赖哪些动态库，否则盲目修复只会浪费时间。
用otool -L查看APP主可执行文件的依赖列表
这一步操作起来很简单，直接把文件拖进去就行。打开终端，输入以下命令：
otool -L /Applications/微信.app/Contents/MacOS/WeChat
注意路径必须指向.app包内部的可执行文件，而不是.app本身。【/Contents/MacOS/】是关键路径，漏掉就报错“no such file”。如果你不确定可执行文件名，可以先执行ls /Applications/微信.app/Contents/MacOS/确认。
用otool -l检查rpath和加载命令细节
当otool -L输出里出现@rpath开头的路径，说明该依赖靠运行时搜索路径加载，此时必须查清rpath是否设置正确。执行：
otool -l /Applications/微信.app/Contents/MacOS/WeChat | grep -A2 -B2 LC_RPATH
输出中会显示实际写入的rpath值，比如@executable_path/../Frameworks。如果这个路径在APP包内并不存在对应目录，运行时就会报“Library not loaded”。【rpath为空或指向不存在的相对路径，是90%依赖失败的直接原因】。
递归扫描所有嵌套dylib的依赖（含第三方框架）
有些APP依赖的不是系统库，而是自己打包的.framework或独立.dylib，它们可能还有自己的依赖链。要彻底摸清，需逐层展开：
第一步：提取APP主程序所有依赖中的非系统库（排除/usr/lib、/System/Library）
第二步：对每个非系统库再次执行otool -L，观察其自身依赖
第三步：若发现某dylib依赖另一个未出现在APP包内的库，就要手动补全或用install_name_tool修正路径
例如，若看到libcrypto.1.1.dylib → /usr/local/opt/openssl/lib/libcrypto.1.1.dylib，说明它硬编码指向Homebrew安装路径，脱离该环境必然失败。
