Gatekeeper 并非限制开发者，而是强制实施可验证、可追溯、可审计的分发规范；所有面向终端用户的 GUI 应用必须用 Apple Developer ID 签名（99 美元/年），未签名应用双击被拦截但本地调试不受限；自 macOS 10.15 起还需公证，否则首次运行仍提示“无法验证开发者”；分发渠道决定 Gatekeeper 行为：App Store 自动通过，官网直装需签名+公证，TestFlight 和企业签名有特定适用范围；合法绕过方式存在但受严格限制。
gatekeeper 对应用开发者不是“限制”，而是强制引入一套可验证、可追溯、可审计的分发规范。它不阻止开发，但要求发布行为符合苹果生态的安全基线。
签名是门槛，不是障碍
所有面向终端用户分发的图形界面应用，必须使用 Apple Developer ID 证书签名。这一步无法跳过，但成本明确（99 美元/年）、流程标准化。未签名的应用在双击运行时会被拦截，但不影响本地调试（Xcode 构建、命令行执行、模拟器运行均不受限）。
- 签名验证失败常见原因：证书过期、Bundle ID 不匹配、签名时遗漏资源文件
- 可通过
codesign -dv /path/to/App.app快速检查签名状态 - 签名本身不保证上架 App Store，仅是 Gatekeeper 接受的前提条件
公证（Notarization）已成为硬性要求
自 macOS 10.15 起，仅签名已不够。应用必须上传至 Apple Notary Service 进行自动化扫描，并将公证票证嵌入二进制中。未公证的已签名应用，在用户首次运行时仍会触发“无法验证开发者”提示。
- 公证过程全自动，无需人工审核，通常几分钟内完成
- 需配合
xcodebuild -exportArchive或altool（已逐步迁至 notarytool）提交 - 若被拒绝，Apple 会返回具体错误（如含私有 API、打包异常、证书问题），需针对性修复后重提
分发渠道决定 Gatekeeper 行为
Gatekeeper 的拦截逻辑与应用来源强绑定，开发者需按目标渠道设计交付方式：
- App Store 分发：自动通过 Gatekeeper，无需额外签名或公证（由 App Store 处理）
- 官网直装（.dmg/.pkg）：必须 Developer ID 签名 + 公证，否则用户双击即拦截
- 内部测试（如 TestFlight 或企业签名）：TestFlight 自动处理；企业签名仅限 MDM 管理设备，普通 Mac 不认
- GitHub 发布页、开源项目归档：推荐提供 .zip（非 .dmg）+ 明确指引用户用 Control+点击打开，避免用户误以为“软件损坏”
绕过机制存在，但有明确边界
开发者可合法绕过 Gatekeeper 进行测试，但系统设计上已收窄权限范围：
-
xattr -d com.apple.quarantine可清除下载隔离标记，适用于已公证但因网络问题未验证成功的场景 -
spctl --add --label "DevBuild"可为特定路径或签名添加白名单规则，比全局禁用更安全 -
sudo spctl --master-disable已被 macOS Sequoia 及后续版本进一步限制，需先启用“任何来源”选项且重启 Terminal 才生效 - 终端直接执行脚本或本地构建的二进制（如
./mytool）默认不受 Gatekeeper 拦截——这是留给开发者的合理空间
