macOS应用签名验证是动态持续的，每次启动、更新或关键操作均重新校验；通过codesign和spctl命令可即时检测签名有效性、公证状态及系统策略执行结果。
macos 应用安装后，系统不会“一劳永逸”地信任该应用。签名验证是持续生效的，每次启动、更新或关键操作时都会重新校验——这不是一次性检查，而是运行时的动态防护机制。
启动时自动触发 Gatekeeper 二次验证
即使应用已成功安装，首次运行仍会触发 Gatekeeper 的实时校验：
- 系统读取应用 bundle 中的
CodeSignature目录，验证签名是否由有效 Developer ID 或 Apple 签发 - 检查公证票据（notarization ticket）是否已钉住（stapled），且未被 Apple 吊销
- 若签名失效、证书过期、或票据缺失，仍会弹出“无法验证开发者”提示，哪怕此前已安装数月
用 codesign 手动验证签名状态
终端命令可即时确认当前签名有效性：
-
codesign --display --verbose=4 /Applications/YourApp.app：查看签名证书链、时间戳、公证状态 -
codesign --verify --deep --strict /Applications/YourApp.app：执行深度完整性校验（含嵌套框架、资源） - 输出中出现
signed Bundle with Mach-O thin (x86_64)和sealed with restriction表示签名完整；若提示code object is not signed at all或invalid signature，说明签名已被破坏或移除
spctl 检查系统级信任策略执行结果
spctl 反映 Gatekeeper 实际放行决策，比 codesign 更贴近真实运行环境：
-
spctl --assess --type execute /Applications/YourApp.app：返回accepted表示通过当前策略 - 若返回
rejected，常见原因包括：证书被吊销、公证票据过期、系统时间偏差超 5 分钟、或管理员禁用了“已识别开发者”选项 - 配合
--raw参数可获取详细评估日志，用于排查策略拦截细节
签名失效后的典型表现与响应逻辑
签名问题通常不表现为崩溃，而是静默降级或拦截：
- 应用能启动但部分功能受限（如无法访问 Keychain、调用 TCC 权限面板失败）
- 自动更新（Sparkle）在下载后验证失败，直接中止安装流程
- 系统日志（
log show --predicate 'subsystem == "com.apple.securityd" || subsystem == "com.apple.gatekeeper"' --last 1h）中频繁出现signature validation failed记录 - 用户无感知时，XProtect 可能基于签名异常行为触发后台扫描并上报
