gatekeeper并非阻止下载，而是精准拦截首次运行：仅当双击.app、执行.pkg或首次启动可执行文件时，基于代码签名有效、苹果公证通过、符合来源策略这三重条件进行校验，任一缺失即拒绝授予cpu执行权。
gatekeeper 不是靠“阻止文件下载”来防护，而是精准卡在“运行前一刻”——它只在用户双击.app、执行.pkg、或首次启动可执行文件时才介入检查。拦截的本质，是拒绝未通过三重验证的程序获得cpu执行权。
三重验证：签名、公证、来源
Gatekeeper 的拦截逻辑基于三个硬性条件，缺一不可：
-
代码签名有效：应用必须带有苹果签发的 Developer ID 或 Mac App Store 证书，且签名未被篡改（用
codesign -dv可验证） - 已通过苹果公证（Notarization）：自 macOS Ventura 起，所有 Intel 架构的非 App Store 应用必须完成公证；Apple Silicon 应用虽暂无强制要求，但未公证仍会触发警告
- 符合系统设置的来源策略：比如你只勾选了“App Store”，那哪怕签名+公证都齐全，来自开发者官网的 .dmg 也会被直接拦截，连“仍要打开”按钮都不显示
拦截发生的典型场景
不是所有操作都会触发 Gatekeeper，它只盯住“首次执行”这个关键节点：
- 双击一个刚从 Safari 下载的 .app，弹出“无法验证开发者”警告
- 运行
installer -pkg安装未签名的 .pkg 包，系统直接中止并提示“已损坏” - 在终端执行
open /path/to/app.app，同样受策略限制，不会跳过校验 - 注意：它不拦截 curl 下载、bash -c 执行、或 AppleScript 调用系统命令——这些属于用户主动授权行为，Gatekeeper 默认放行
为什么有时“仍要打开”也失效？
这不是 Gatekeeper 失灵，而是系统叠加了更严格的判断：
- 文件被标记
com.apple.quarantine属性（浏览器下载自动添加），但签名或公证校验失败 - 应用使用了被苹果撤销的开发者证书（如 2025 年 MacSync 事件后批量吊销）
- macOS Sequoia 15+ 或 Tahoe 26+ 版本新增了对 App Store 购买绑定、Apple ID 权限的交叉验证，绕过公证的“伪签名”会被识别并拒之门外
真正有效的防御动作
依赖 Gatekeeper 自动拦截远远不够，关键在主动收紧和及时响应：
- 在“系统设置 > 隐私与安全性 > 安全性”中，仅保留“App Store”，关闭“App Store 和被认可的开发者”
- 启用终端粘贴防护：确保“系统设置 > 隐私与安全性 > 终端”里勾选“阻止粘贴潜在恶意命令”
- 定期检查“完全磁盘访问”和“辅助功能”列表，移除陌生条目——TCC 权限常被恶意脚本借壳调用
- 发现可疑应用立即断网，用 Activity Monitor 终止进程，并运行
spctl --assess --type execute /path手动验证其状态
