gatekeeper校验对日常使用几乎无感知，仅在首次运行时毫秒级触发轻量检查，平均耗时10–80毫秒，真正影响体验的是校验失败后的阻断行为而非校验本身。

gatekeeper 的校验过程对日常使用几乎无感知，它不拖慢启动速度，也不占用持续资源。它的性能损耗集中在“首次运行”那一瞬间，且设计上已做极致优化。

校验发生在启动前的毫秒级窗口
Gatekeeper 不在后台常驻扫描，也不轮询监控。它只在用户双击应用、或通过终端执行 open /path/to.app 时触发一次轻量检查。整个流程平均耗时 10–80 毫秒（实测 macOS Sonoma 14.5 / Sequoia 15），取决于三项因素：

• 应用包大小（签名数据读取时间）
• 是否需联网验证公证票据（spctl --assess 会缓存近期结果，离线时走本地签名验证）
• 系统磁盘 I/O 响应（APFS 加密卷下略有延迟，但差异＜5 ms）

真正影响体验的不是 Gatekeeper 本身，而是它暴露的问题
你感觉“卡顿”或“打不开”，通常不是校验慢，而是校验失败后系统阻断了后续动作：

• 签名无效 → 停在弹窗，不加载进程
• 公证票据缺失或过期 → 等待超时（默认约 3 秒）后报错
• quarantine 属性存在 + 签名弱 → 触发额外完整性扫描（如检查嵌入式 framework 是否被篡改）

这些失败路径会让人误以为“Gatekeeper 很慢”，实则是它及时发现了问题，阻止了不可信代码进入内存。

可验证的低开销证据
终端执行以下命令即可确认：

time spctl --assess --type execute /Applications/TextEdit.app

输出类似：

macOS Automator Services

部署和使用军舰的 macOS Automator 自动化服务集合。包含 5 个实用工作流：PDF转JPG、PNG重命名并转JPG、图像拼接、解压RAR、顺序命名图像文件。一键安装所有服务到 ~/Library/Services/ 目录。使用场景：(1) "安装我的自动化服务"，(2) "部署所有 Automato...

下载

/Applications/TextEdit.app: accepted
real    0m0.021s
user    0m0.004s
sys     0m0.007s

这说明 Gatekeeper 主体逻辑（签名+公证校验）本身仅消耗 21 毫秒真实时间，其中大部分是文件系统访问和证书链解析，而非 CPU 密集型运算。

开发者侧的性能注意点
若你自己发布应用，以下操作会显著增加校验延迟（非 Gatekeeper 责任，但用户感知为“启动慢”）：

• 在 .app 内嵌入未签名的第三方 dylib 或脚本（触发递归签名验证）
• Info.plist 中声明了大量 entitlements 却未在签名时正确嵌入（导致 codesign 验证回退重试）
• 使用自定义 hardened runtime 配置但未启用公证（系统会多做一次本地恶意行为启发式分析）

简言之，Gatekeeper 是个安静守门人——它不巡逻，只验票；不拦路，只拒假票。它的性能损耗不是负担，而是信任建立的必要开销。