本质是dyld运行时找不到或加载了错误版本的依赖库，需区分路径错误、rpath缺失、签名失效或加载顺序问题，而非库文件物理缺失。
macos 上 homebrew 安装的软件运行时报“library not loaded”或“image not found”，本质不是库文件缺失，而是动态链接器（dyld）在运行时找不到、或加载了错误版本的依赖库。关键要分清：是路径错了、rpath 没写、签名失效，还是加载顺序/符号可见性问题。
确认 dyld 实际加载了哪个库
别只信 otool -L ——它只显示编译时写的依赖路径，不反映真实行为。很多问题就出在这里：你看到它依赖 /opt/homebrew/lib/libcurl.dylib，但运行时却加载了系统自带的 /usr/lib/libcurl.dylib（ABI 不兼容）。
- 终端执行：
dyld_print_libs=1 /Applications/MyApp.app/Contents/MacOS/MyApp 2>&1 | grep libname（把libname换成如libssl、libmpich） - 输出中第一行匹配到的路径，就是 dyld 真正打开的那个文件
- GUI 应用若终端不生效，改用：
launchctl setenv DYLD_PRINT_LIBS 1，再从 Dock 启动
修复 rpath 缺失或错误
Homebrew 或源码编译的库常因 rpath 未写入，导致间接依赖失败。只改主依赖路径，却不加搜索路径，等于半途而废。
- 先修正直接依赖：
install_name_tool -change "@rpath/libpq.dylib" "/opt/homebrew/lib/libpq.dylib" /path/to/binary - 再补运行时搜索路径：
install_name_tool -add_rpath "/opt/homebrew/lib" /path/to/binary - 验证是否写入：
otool -l /path/to/binary | grep -A2 LC_RPATH，确认路径存在且拼写无误
处理 ctypes 加载 MPICH 等模块化库失败
在 Python 中用 ctypes.cdll.LoadLibrary() 直接加载 libmpich.dylib 报 “symbol not found in flat namespace”，是因为 macOS 默认用 RTLD_LOCAL 加载，符号不全局可见。
- ✅ 正确写法：
mpich = ctypes.CDLL("/opt/homebrew/lib/libmpich.dylib", mode=ctypes.RTLD_GLOBAL) - 不要用
ctypes.cdll.LoadLibrary()或默认RTLD_LOCAL模式 - 路径需准确：Apple Silicon 是
/opt/homebrew/lib/，Intel Mac 通常是/usr/local/lib/，可用brew --prefix mpich确认 - 若还需加载
libmpi.dylib等，建议按依赖顺序依次以RTLD_GLOBAL加载
绕过 Gatekeeper 干扰与重签名
升级后系统会清空第三方应用的 Gatekeeper 授权，旧签名也可能因路径变动或证书过期失效，触发 errSecCSReqFailed。
- 先尝试右键 App → “打开” → 点“仍要打开”，获取临时授权
- 若无效，清除隔离属性：
sudo xattr -r -d com.apple.quarantine "/Applications/MyApp.app" - 再强制重签名：
sudo codesign --force --deep --sign - "/Applications/MyApp.app"
