macos应用更新后依赖库冲突的本质是dyld运行时加载的库与预期不一致；需用dyld_print_libs定位真实加载路径，补全rpath、重签名、检查权限及系统扩展授权。
macos 应用更新后出现依赖库冲突，本质是运行时动态链接环境发生了偏移——不是应用坏了，而是 dyld 实际加载的库和你预期的不一致。排查要绕过静态信息（比如 otool -l），直击真实行为；修复要兼顾路径、rpath、签名和权限，缺一不可。
先看它到底加载了哪个库
otool -L 显示的是编译时硬编码的路径，不能反映真实加载行为。很多问题就卡在这里：你看到它依赖 /opt/homebrew/lib/libssl.dylib，但运行时却加载了 /usr/lib/libssl.dylib（ABI 不兼容）。
- 终端执行：
dyld_print_libs=1 /Applications/你的应用.app/Contents/MacOS/可执行文件名 2>&1 | grep libssl（把 libssl 换成你怀疑的库名） - 输出中第一行匹配到的路径，就是 dyld 真正打开的那个文件
- GUI 应用在终端里可能不生效，改用：
launchctl setenv DYLD_PRINT_LIBS 1，然后从 Dock 或 Finder 启动应用
补上缺失的 rpath，别只改一个路径
Homebrew 或手动编译的库常因 rpath 没写入，导致间接依赖失败。只用 install_name_tool -change 替换主依赖，却不加搜索路径，等于修了半条路。
- 先改直接依赖：
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）或系统扩展的应用，升级后常被禁用或拒绝加载。
- 前往「系统设置 → 隐私与安全性 → 完全磁盘访问」，确认应用已获授权
- 检查「系统设置 → 隐私与安全性 → 扩展」，查看对应系统扩展是否启用
- Apple Silicon 设备上，右键应用 → 「显示简介」→ 勾选「使用 Rosetta 打开」，测试 Intel 架构兼容性
- 若涉及 kext，需在启动时按住 Cmd+R 进入恢复模式，运行
csrutil enable --without kext（仅调试，不推荐长期关闭 SIP）
