macos应用来源验证机制已演进为三级闭环：本地签名验证、在线公证状态检查、离线票据验证，缺一不可。gatekeeper（2012）、公证机制（2019）、强化运行时（2020起）层层递进，在保障易用性前提下阻断恶意软件运行。
macos 应用来源验证机制不是一成不变的，而是随着威胁环境变化和系统能力升级持续演进，核心目标始终是：在不牺牲易用性的前提下，把恶意软件挡在运行之前。
Gatekeeper 的诞生（2012 年，OS X 10.8 Mountain Lion）
这是第一道系统级防线，替代传统反病毒扫描思路。它采用白名单机制，默认只允许两类应用运行：
- 来自 Mac App Store 的应用（经苹果人工审核）
- 使用 Apple 颁发的“开发者 ID”证书签名的应用（验证开发者身份，但不检查代码内容）
关键标志是 com.apple.quarantine 扩展属性——所有从网络下载的文件自动带上它，成为 Gatekeeper 判定“外来应用”的依据。此时仅靠签名就能绕过大部分警告。
公证机制引入（2019 年，macOS 10.14.5 Mojave）
签名只能证明“谁写的”，无法说明“写得安不安全”。苹果由此推出 Notarization（公证）：
- 开发者提交二进制包到苹果服务器，由自动化系统扫描恶意行为、私有 API 调用、已知漏洞等
- 通过后生成数字票据（ticket），可装订（staple）进应用包内
- 用户首次运行时，系统既验本地签名，也查该票据有效性
未公证的已签名应用，会触发更明确的提示：“无法检查是否包含恶意软件”，而非旧版模糊的“无法验证开发者”。
强化运行时与策略收紧（2020 年起，Catalina 及后续版本）
公证解决分发前风险，强化运行时（Hardened Runtime）则聚焦运行中防护：
- 要求启用特定安全选项（如禁用
dylib动态加载、限制调试器附加等） - 与沙盒不同，它不强制隔离，而是“默认允许，按需拒绝”，更适合专业工具
- 自 macOS 10.15 Catalina 起，未启用强化运行时的公证应用，首次运行仍会显示警告，需用户右键选择“打开”确认
同时，苹果不断封堵绕过路径：修复 Achilles 等漏洞、撤销被滥用的开发者证书、限制隔空投送共享商业软件等行为，让“被认可的开发者”真正代表可信分发链。
三级验证闭环（当前稳定形态，macOS Sequoia / Tahoe）
如今一个合规应用需通过三阶段协同验证：
- 本地签名验证：检查证书有效性、文件完整性（篡改即报“已损坏”）
- 在线公证状态检查：首次运行时联网确认票据未被撤销
- 离线票据验证：装订后的 ticket 随包分发，断网也能完成最终判断
缺任何一环，用户都会遇到阻拦或警告。而“App Store 和被认可的开发者”这一系统设置项，正是对这整套机制的用户侧封装——它放行的是签名+公证+强化运行时配置齐全的应用，不是单纯“有开发者署名”就行。
