活动监视器不显示进程加载的dylib，需用lsof -p PID | grep .dylib配合查看；可疑dylib应通过codesign -dv和otool -L验证签名及依赖；SIP或沙盒限制导致权限拒绝属正常现象。
活动监视器本身不显示进程加载的动态链接库（dylib），它只提供 cpu、内存、网络等资源使用概况。要检查某个进程实际链接了哪些 dylib，需结合终端命令与活动监视器配合操作。
先在活动监视器中定位目标进程
打开活动监视器（Command + 空格 → 输入“活动监视器”），切换到“所有进程，分层显示”模式，按 CPU 或内存排序找到你要分析的进程。记下它的 PID（进程 ID）——如果“PID”列未显示，右键点击列标题 → 勾选“PID”即可。
用 lsof 查看该进程加载的所有动态库
打开终端，执行以下命令（将 PID 替换为实际数字）：
- lsof -p PID | grep .dylib —— 列出该进程当前打开的所有 dylib 文件
- lsof -p PID | grep -E '\.(dylib|so)$' —— 同时匹配 dylib 和部分第三方 so 库（较少见）
- 若输出过长，可加 | less 分页查看，按 q 退出
典型结果如：/usr/lib/libSystem.B.dylib、/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit，这些属于系统框架；而指向 ~/Library/ 或第三方 App Bundle 内部路径的 dylib，需重点关注是否可疑。
进一步确认 dylib 来源与签名
对某条可疑 dylib 路径，可在终端中验证其完整性：
- codesign -dv /完整路径/to/library.dylib —— 查看签名信息，确认是否由 Apple 或可信开发者签发
- otool -L /完整路径/to/library.dylib —— 查看该 dylib 自身依赖的其他库（即“递归依赖”）
- 若路径含
~或Application Support，且无有效签名，建议用访达右键“显示简介”检查“通用”标签下的“已锁定”和“已验证”状态
注意系统限制与常见情况
macOS 对系统进程（如 kernel_task、launchd）或沙盒化 App（如 Safari、Notes）会限制 dylib 列出权限，lsof 可能返回“permission denied”。这不是操作错误，而是 SIP（系统完整性保护）或 sandbox 的正常行为。此时可关注其父进程或启动方式（如 launchctl list），而非强行读取底层库。
多数用户级 App 加载的 dylib 都位于自身 bundle 内（如 MyApp.app/Contents/Frameworks/）或标准系统路径，非必要无需干预。真正需要警惕的是：未经签名、来自下载目录、被注入到多个进程中的同名 dylib。
