修复macos应用升级后库加载错误需先用dyld_print_libs=1验证真实加载路径，再用install_name_tool -change和-add_rpath两步修正依赖及rpath，最后处理gatekeeper授权、重签名、系统扩展和rosetta兼容性问题。
macOS 应用升级后出现库加载错误（如 dyld: Library not loaded、image not found），通常不是应用本身损坏，而是运行时动态链接环境发生了变化——系统路径、rpath、环境变量或签名状态被重置。修复关键在于确认“实际加载了哪个库”，再针对性调整。
确认真实加载路径，别信 otool -L
otool -L 只显示编译时硬编码的依赖路径，不能反映 dyld 实际行为。很多问题就出在这里：你看到它依赖 /opt/homebrew/lib/libcurl.dylib，但运行时却加载了 /usr/lib/libcurl.dylib（ABI 不兼容）。
正确做法是用运行时日志验证：
- 终端执行：
dyld_print_libs=1 /Applications/你的应用.app/Contents/MacOS/可执行文件名 2>&1 | grep libname（把libname换成如libssl、libhidapi等） - 输出中第一行匹配到的路径，就是 dyld 真正打开的那个文件
- GUI 应用若在终端不生效，改用：
launchctl setenv DYLD_PRINT_LIBS 1，然后从 Dock 或 Finder 启动应用
修复 rpath 缺失或错误，让 dyld 找得到库
Homebrew 或手动编译的库常因 rpath 未写入，导致间接依赖失败。只用 install_name_tool -change 替换主依赖，却不加搜索路径，等于只修了半条路。
标准两步操作（以修复依赖 libpq.dylib 为例）：
- 先改直接依赖：
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，确认路径存在且拼写无误
绕过 Gatekeeper 干扰并重签名
升级后系统会清空第三方应用的 Gatekeeper 授权，同时旧签名可能因证书过期或路径变动失效，触发 errSecCSReqFailed。
分步处理：
- 先尝试右键 App → “打开”，点“仍要打开”获取临时授权
- 若无效，清除隔离属性：
sudo xattr -r -d com.apple.quarantine "/Applications/应用名.app" - 再强制重签名：
sudo codesign --force --deep --sign - "/Applications/应用名.app" - 注意：重签名后需重启应用，部分工具（如 QMK Toolbox）还要求
Resources/下的 dylib 文件权限为-rwxr-xr-x
检查系统扩展与架构兼容性
NTFS 工具、USB 调试器等依赖内核扩展（kext）或系统扩展（system extension）的应用，升级后常被禁用；Apple Silicon Mac 运行 Intel 应用则必须启用 Rosetta。
- 进“系统设置 > 隐私与安全性 > 安全性”，查找灰色提示“允许来自‘XXX’的系统软件”，点“允许”后务必重启
- 右键问题 App → “显示简介”，勾选“使用 Rosetta 打开”（适用于 M1/M2/M3 机型上的 Intel 应用）
- 若应用图标点击无反应，很可能是 Dock 缓存了旧路径：删掉 Dock 图标，再从“应用程序”文件夹拖新版本进去
