XProtect仅扫描同时满足“来自互联网下载、具可执行权限、被识别为潜在可执行体”三条件的文件，如.command、.app内二进制、.pkg/.dmg安装器首次启动；对.plist、.sh、.env等纯文本或非首次调用文件默认跳过，因其设计为守门而非审计，依赖quarantine属性触发且不解析脚本逻辑或资源派生数据。
xprotect 本身不扫描可疑脚本或配置文件——它只在“首次打开”时检查已知恶意行为特征，且仅限特定类型、带 quarantine 属性的可执行内容。对纯文本脚本（如 .sh、.zsh、.plist）、配置文件（如 .json、.conf）或资源派生数据（如 resource fork），xprotect 默认跳过，不解析、不比对、不触发拦截。
哪些脚本会被 XProtect 扫描？
只有同时满足以下全部条件的脚本才可能被纳入扫描范围：
- 来自互联网下载（自动被打上 com.apple.quarantine 属性）
- 具有可执行权限（chmod +x）
- 文件扩展名或 MIME 类型被系统识别为“潜在可执行体”，例如：
• .command（双击运行的 shell 脚本）
• .app 内部的 Contents/MacOS/* 二进制
• .pkg 或 .dmg 中嵌套的安装器 - 首次被用户主动启动（通过双击、open 命令、或 Finder 中点击）
为什么 .plist、.sh、.env 等文件通常逃过扫描？
XProtect 的设计逻辑是“守门而非审计”：它不分析脚本逻辑，也不读取配置内容。常见绕过情形包括：
- .sh 文件未设 quarantine 属性：用 curl -o script.sh 直接写入 /tmp 或 ~/Downloads 后手动 chmod，系统不打隔离标，XProtect 完全不介入
- .plist 不是“首次打开”对象：LaunchAgents 是由 launchd 自动加载，不经过用户点击或 open 调用，XProtect 不感知
- resource fork 隐藏载荷：Install.command 表面无害，真实 payload 存在 com.apple.ResourceFork 扩展属性中，XProtect 不解析该元数据
- base64 / curl | bash 类内存加载：命令未落地为文件，全程在内存中解码执行，XProtect 无文件可查
真正起作用的其实是配套机制
单靠 XProtect 规则无法覆盖脚本风险，需依赖系统级约束协同生效：
- quarantine 属性必须保留：它是 XProtect 启动扫描的唯一开关。禁用自动清除（如终端粘贴警告、禁用 xattr -d）是第一道防线
- Gatekeeper 控制“谁有资格被扫描”：若允许“已识别开发者”，等于放行大量未公证的 Developer ID 应用，其中不少含恶意 .sh 调用链
- LaunchAgents 检查要人工介入：XProtect 不管 plist 内容，但你可以用 ls -la ~/Library/LaunchAgents/ | grep '\.service$' 快速揪出伪装项
- resource fork 需主动查验：下载后立即运行 xattr -l 文件名，发现 >10KB 的 com.apple.ResourceFork 就该停手审查
它不是杀毒软件，也不是配置审计器。它的规则简单直接：只拦已知、只看首次、只信 quarantine。把这点吃透，才能避开“以为被保护了”的错觉。
