Mac软件启动失败若由依赖缺失引发，日志中通常明确记录“找不到库”“符号未定义”或“dlopen失败”，需通过控制台筛选process:yourappname及dyld错误、otool-L检查依赖链、崩溃日志中Binary Images段定位未加载库。
mac 软件启动失败若由依赖缺失引发，日志中通常会明确记录“找不到库”“符号未定义”或“dlopen 失败”等线索。关键不是看崩溃结果，而是抓取进程加载动态库（dylib）和运行时链接（runtime linking）阶段的原始报错——这些信息集中在系统日志、控制台报告及终端调试输出中。
在控制台中筛选启动失败的实时加载日志
很多依赖问题发生在程序刚启动、尚未完全初始化时，此时错误会直接写入内核和系统服务日志：
- 打开“控制台”App，左侧选中本机名称；
- 顶部搜索栏输入 process: yourappname（把 yourappname 替换为你启动失败的软件名，如 Preview、Electron、mytool）；
- 再追加条件：message contains "dlopen" or "library not found" or "symbol not found"；
- 重点查看红色（Error）或橙色（Fault）条目，常见典型提示包括：
dlopen(/path/to/libxxx.dylib, RTLD_GLOBAL | RTLD_PREBOUND): image not found
Symbol not found: _OBJC_CLASS_$_NSProgress
检查 launchd 日志确认服务级依赖失败
如果软件是通过 launchd 启动（如后台守护进程、菜单栏工具、开机自启项），其依赖加载失败会被 launchd 拦截并记录：
- 在控制台中切换到“报告”分类；
- 查找文件名含 yourappname 且扩展名为 .log 或 .stderr 的条目；
- 双击打开，滚动至顶部或搜索 dyld: —— 这是 macOS 动态链接器前缀，所有库加载错误都以它开头；
- 典型输出示例：
dyld[12345]: Library not loaded: @rpath/libcurl.4.dylib
Referenced from: /Applications/MyApp.app/Contents/MacOS/MyApp
Reason: tried: '/usr/lib/libcurl.4.dylib' (no such file), '/System/Library/Frameworks/Curl.framework/Versions/A/Curl' (no compatible version)
用终端命令验证 dylib 依赖链完整性
即使软件没启动成功，也可用系统工具静态检查它的依赖是否可解析：
- 定位主可执行文件路径，例如：
/Applications/MyApp.app/Contents/MacOS/MyApp - 运行命令：
otool -L "/path/to/MyApp" —— 显示该程序声明的所有动态库路径； - 对每一条非系统路径（尤其以 @rpath、@loader_path、@executable_path 开头的），用 ls -l 检查对应文件是否存在；
- 若某 dylib 存在但版本不匹配，可进一步用 file /path/to/libxxx.dylib 查看架构（x86_64/arm64）和兼容性。
从崩溃日志反推缺失依赖（适用于已闪退场景）
若软件启动后立即崩溃，系统会生成 .crash 报告，其中包含 dyld 加载阶段的完整上下文：
- 前往 ~/Library/Logs/DiagnosticReports/，找最新生成的 yourappname_*.crash 文件；
- 用文本编辑器打开，搜索关键词：Exception Type: EXC_CRASH (Code Signature Invalid) 或 dyld；
- 在 “Binary Images” 小节下方，常附有类似提示：
0x102a3c000 - 0x102a43fff libswiftCore.dylib (*)
(*) dyld could not load inserted library '/usr/lib/libcrypto.dylib' - 括号中标注的 “(*)” 表示该库未能成功加载，即实际缺失或签名损坏。
