Gatekeeper不校验更新行为本身，只校验更新后新应用包的签名与公证票据是否合法有效；下载时打quarantine标记，首次运行时通过spctl评估并协同AMFI执行最终裁定。
gatekeeper 不直接校验“更新行为”本身，而是校验更新后产生的新应用包是否可信。它不关心你是点“更新”按钮还是手动替换.app，只认最终落地的那个文件有没有带合法签名和公证票据。
更新包下载阶段：隔离属性（quarantine）触发首次检查
当更新框架（如 Sparkle）从网络下载新的 .app 或 .pkg 时，系统会自动打上 com.apple.quarantine 扩展属性。这个标记就像一张“待审通行证”，确保下次双击或安装时 Gatekeeper 必须介入：
- 下载完成但尚未运行 → 文件带 quarantine 属性，但无实际拦截
- 用户点击更新后的应用图标 → Gatekeeper 立即读取签名与公证状态，决定是否放行
- 若签名无效、证书过期、未公证或哈希不匹配，弹出“无法验证开发者”
更新内容落地阶段：签名与公证票据必须完整继承
很多失败不是出在下载，而是更新过程破坏了信任链。Gatekeeper 校验的是最终的 .app 目录结构，重点看三处：
- _CodeSignature/CodeResources 是否存在且未被篡改（任何资源文件增删都会导致校验失败）
- 签名证书是否由 Apple Root CA 信任链签发（Developer ID Application 证书需有效且未吊销）
- 公证票据（notarization ticket）是否嵌入到包中（通过 stapler staple 或 xcodebuild -exportArchive 自动注入）
常见问题：更新脚本用 rsync 或 cp 替换整个 Contents/ 目录，却漏掉 _CodeSignature；或用 Automator 打包后未重签名，导致原有签名失效。
更新后首次启动：Gatekeeper 与 AMFI 协同执行最终裁定
即使更新包通过了 Sparkle 内部校验（如 SUCodeSigningVerifier），Gatekeeper 仍会在用户首次双击时重新评估：
- 调用 spctl --assess --type execute /Applications/YourApp.app 做实时判定
- 若返回 accepted，继续加载；若返回 rejected，弹窗拦截
- 内核级 AMFI（Apple Mobile File Integrity）同步验证二进制签名，防止 dylib 注入等运行时篡改
注意：管理员密码输入环节发生在安装（.pkg）或拖入 /Applications 时，属于 SIP 和权限控制范畴，和 Gatekeeper 的“能否运行”是两个独立判断。
绕过与调试：临时放行 ≠ 关闭安全，仅用于验证路径
遇到“无法验证”提示时，可快速定位是签名、公证还是系统设置问题：
- 右键 → “打开” → “仍要打开”：仅解除本次执行限制，不改变签名状态
- 终端执行 xattr -d com.apple.quarantine /Applications/YourApp.app：清除隔离标记，再双击测试是否仍报错（排除 quarantine 干扰）
- 运行 codesign -dv /Applications/YourApp.app 查看签名详情，确认 Authority 字段含 Developer ID
- 运行 spctl --assess --verbose=4 /Applications/YourApp.app 获取详细拒绝原因（如 “origin invalid” 或 “notarization failed”）
