Gatekeeper虽不直接耗CPU，但验证失败会引发进程卡死、重试及超时，叠加quarantine属性重复校验、TCC权限缺失和M芯片更严签名检查，显著拖慢响应速度与稳定性。
gatekeeper 本身不消耗 cpu 或拖慢系统运行，但它引发的连锁反应会显著影响响应速度和稳定性——尤其是当验证失败反复发生时。
验证失败导致进程卡死或重试
Gatekeeper 不直接运行在前台，但每次启动未签名/未公证应用时，它会触发后台校验流程。若校验失败（比如签名无效、公证票据过期、证书被撤销），系统不会简单报错退出，而是可能让进程挂起、静默失败，或触发多次重试。
- 终端脚本调用
osascript或defaults时突然中断，日志里反复出现Authorization denied或Failed to get authorization for TCCService - 自动化工具（如 Hammerspoon、Raycast 插件）启动后图标常驻但功能失灵，背后是 Gatekeeper 拦截导致其无法加载依赖模块
- 双击应用无响应，鼠标转圈数秒后退回桌面——这不是程序崩溃，而是 Gatekeeper 验证超时后放弃加载
隔离属性（quarantine）带来重复开销
从网页下载的文件默认被打上 com.apple.quarantine 扩展属性。即使应用已签名且公证，每次执行仍可能触发 Gatekeeper 的二次检查，包括扫描、哈希比对、网络票据验证等。
macOS Automator Services
下载
部署和使用军舰的 macOS Automator 自动化服务集合。包含 5 个实用工作流：PDF转JPG、PNG重命名并转JPG、图像拼接、解压RAR、顺序命名图像文件。一键安装所有服务到 ~/Library/Services/ 目录。使用场景：(1) "安装我的自动化服务"，(2) "部署所有 Automato...
- 用
ls -l@ /Applications/MyTool.app查看，若输出含com.apple.quarantine，说明该应用每次启动都经历完整验证链 - 频繁调用的命令行工具（如
jq、yq、自研 CLI）若带 quarantine 标记，会导致 shell 脚本延迟明显，尤其在循环中多次调用时 - 清除方式简单：
xattr -d com.apple.quarantine /path/to/tool，无需全局禁用 Gatekeeper
权限缺失与 Gatekeeper 交互加剧性能问题
Gatekeeper 和 TCC（隐私权限框架）虽独立运作，但常协同失效。例如：一个未公证的应用即使绕过 Gatekeeper 启动，也可能因缺少“完全磁盘访问”权限，导致 Spotlight（mds）、共享服务（sharingd）持续轮询、超时、重试。
- 打开「活动监视器」，筛选
mds、sharingd、locationd，若长期占用 >20% CPU，先查对应应用是否在「完全磁盘访问」列表中 - Terminal 若没获得完全磁盘访问权，执行
find ~/Library -name "*.plist"可能卡住数秒——不是磁盘慢，而是权限拒绝后反复降级尝试 - 修复后不必重启系统，只需退出 Terminal 再重开，或运行一次曾失败的命令验证是否立即返回
开发场景下的隐性效率损耗
开发者日常高频接触未签名构建产物（CI 输出、本地打包、GitHub Release），若依赖“右键 → 打开 → 仍要打开”，每次操作都重置单次信任状态，无法积累验证缓存，导致重复校验开销累积。
- 相比
sudo spctl --master-disable这种一刀切方案，更推荐用spctl --add /path/to/app为特定路径或开发者 ID 添加白名单 - 用
spctl --assess --type execute /path/to/app可快速判断当前校验结果，避免盲目重试 - M 系列芯片 Mac 对签名完整性校验更严格，同一份 build 在 Intel 和 Apple Silicon 上表现可能不同，需分别验证
