macos应用签名是安全策略的触发开关，需匹配developer id authority且teamidentifier有效，否则gatekeeper拦截；签名必须配合苹果公证（notarization）才被允许执行，二者缺一不可，并受amfi、sip及quarantine属性共同约束。
macos 应用签名不是“贴个标签”那么简单，它和系统安全策略是深度绑定的执行关系——签名是凭证，策略是裁判，二者共同决定一个应用能不能运行、能访问什么、在哪儿运行。
签名是安全策略的触发开关
Gatekeeper 不会主动拦截所有第三方软件，它只对带 com.apple.quarantine 属性的文件（比如从网页下载的 .app 或 .pkg）启动校验流程；而这个流程的第一步，就是读取代码签名。没有签名，直接拒绝；有签名但 Authority 不是 Developer ID 或 Apple Distribution，也视为无效。签名就像一张入场券，没它连安检通道都进不去。
- Authority 显示 adhoc 或 unidentified developer → Gatekeeper 拦截，提示“来自身份不明的开发者”
- Authority 正确但 TeamIdentifier 为空或不匹配 → 系统无法关联到可信开发者账号，同样不信任
- 签名存在但 valid on disk 为 no → 文件被修改过，哈希校验失败，“已损坏”弹窗由此而来
公证（Notarization）是签名的“官方背书”
从 macOS Catalina（10.15）起，仅签名还不够。Apple 要求所有分发到用户端的 Developer ID 应用必须经过公证服务扫描。这步不是可选动作，而是策略硬性要求：Ventura 及更新版本中，未公证的应用默认无法执行，哪怕签名完全正确。
- 公证票据（ticket）嵌入在二进制中，
spctl --assess --type execute YourApp.app输出 accepted 才算真正过关 - 公证可能因恶意行为、证书吊销、时间戳异常或系统时间偏差而失效，此时即使重签名也无法绕过
- 公证状态独立于签名存在——签名有效 ≠ 公证有效，两者缺一不可
AMFI 与 SIP 构成底层执行约束
签名和公证通过 Gatekeeper 后，应用才真正进入运行阶段。这时 AMFI（Apple Mobile File Integrity）开始介入：它强制验证每个加载的可执行文件和动态库是否带有有效签名，并检查 entitlements 是否越权。SIP 则保护系统路径（如 /System、/usr），确保安装器写入时必须经管理员授权。
- AMFI 位掩码设为
0x2可放宽签名验证，适用于老旧设备兼容场景，但会降低安全性 - SIP 关闭不能跳过签名检查，只影响路径写入权限；签名缺失的应用即使 SIP 关闭也无法启动
- 沙盒 entitlements（如
com.apple.security.app-sandbox）若声明不当，AMFI 会在运行时拒绝加载，而非安装时报错
隔离属性（quarantine）是隐藏的“第二道门”
很多用户以为过了 Gatekeeper 就万事大吉，却忽略了 com.apple.quarantine 这个扩展属性。它由浏览器或邮件客户端自动添加，独立于签名存在。即使应用已签名+公证，只要这个属性还在，系统仍可能二次拦截。
-
xattr -l YourApp.app可查看是否带 quarantine 属性 -
xattr -d com.apple.quarantine YourApp.app可手动清除（仅限可信来源） - Control + 点击“打开”会临时绕过 quarantine 检查，但不会删除该属性
