2026 年 macOS 应用公证与 Stapler 完全指南：
在按天租用 Mac 上跑通 notarytool 与分发前检查清单
需要对外分发 dmg/pkg、或企业内网推送安装包的开发者，往往卡在「代码签名已做，但 Gatekeeper 仍拦截」——这通常不是 Apple「刁难」，而是未走通公证（Notarization）与装订（Staple）链路。本文回答三件事：谁适合在按天租用的原生 macOS上完成整条流水线、如何把 开发者 ID、notarytool、stapler 写成可审计步骤、如何用对照表 + 五条落地步骤 + 三条可引用数据把拒绝原因收敛成可复现 runbook。文内链到 临时签名与打包指南、按天租用 Mac 完全指南（SSH/VNC） 与 提审与 Xcode 环境，便于你在短期窗口内把「能签」与「能发」分层处理。
本文目录
01. 三类痛点：公证窗口、钥匙串边界与租用机污染
1）短期窗口与「半套流水线」：公证需要可用的开发者账号、本机可登录的 Apple ID 会话、以及稳定的出口；在按天租用场景里，若只预留了编译时间却未预留 15～45 分钟的公证轮询与装订，很容易出现「包已签、但用户下载时仍被拦截」的交付事故。把公证写进与 临时签名同级的检查表，而不是事后补救。
2）钥匙串与证书在多人租用机上的串扰：上一任用户残留的 login.keychain 或自动导入的「错误开发者 ID」会让 codesign 看似成功、notarytool 却在提交阶段报 身份不匹配或权限不足。短期方案建议：为公证任务单独创建 macOS 用户目录，并在任务结束后导出脱敏日志而非导出私钥材料。
3）网络与代理对公证 API 的影响：企业代理若未放行 Apple 公证端点，会表现为长时间 pending 或直接 TLS 失败；这与 SSH/VNC FAQ 里讨论的「延迟与带宽」不同，需要单独核对出站白名单。
02. 仅签名 vs 公证：决策边界与 2026 常见误区
对 macOS 分发而言，代码签名解决「完整性」，公证解决「Apple 侧风险扫描 + Gatekeeper 放行策略」。用户从网上下载的 dmg/pkg，在未公证时可能被标记为隔离属性，触发更严格的提示；装订后的 ticket 能让系统分发链路更一致。误区包括：「公证等于上架 Mac App Store」（不需要，公证面向开发者 ID 分发）；「公证可以替代正确的 Hardened Runtime 与 Entitlements」（不能，公证失败常与沙盒/权限声明不一致有关）。若你的目标还包括 iOS 侧提审，请把 Xcode 与 SDK 环境与本文 macOS 分发链拆开评估，避免混用同一套假设。
在租用机上，建议把 Archive/导出 与 公证 分成两个「可验证里程碑」：先确认 codesign --verify --deep --strict 与 spctl 对本地构建的行为符合预期，再进入 notarytool；这样拒绝原因更容易定位到「签名层」还是「公证内容扫描层」。若团队使用 CI 触发公证，也要把机器身份（哪台 Mac、哪个钥匙串）写进流水线变量，避免「同一脚本在本地过、在租用机不过」的隐性漂移。
补充一项在 2026 年仍高频出现的细节：Hardened Runtime 与 Entitlements 若与实际上网能力、文件访问路径不一致，公证日志里可能出现「行为与声明不匹配」类提示。此时不要急于重传同一二进制，应先回到 Xcode 的 Signing & Capabilities 与 codesign -d --entitlements :- 导出结果逐项对照，再决定是收紧权限还是调整实现。把这类对照写进团队模板，可在租用窗口内显著减少无效重试。
03. 分发路径对照表：dmg、pkg 与 zip 的风险矩阵
没有单一「最省事」格式；下表帮助你在数分钟内对齐交付方式与运维成本。
| 维度 | dmg | pkg | zip |
|---|---|---|---|
| 用户感知体验 | 拖拽安装，适合桌面应用 | 适合驱动/系统组件/预置脚本 | 适合 CLI/工具包，步骤略多 |
| 签名与公证注意点 | 需关注内层 .app 与外层镜像一致性 | 脚本与 payload 分层多，易漏签 | 解压后属性与隔离标记要验证 |
| 在租用机上的典型风险 | 桌面会话与 Finder 交互多 | 需要 root/安装器权限管理 | 易被忽略「未装订但仍可下载」 |
| 适合阶段 | 对外 Beta 与设计师工具 | IT 部署与企业内网 | 自动化交付与 CI 产物 |
04. 落地步骤：从提交到装订的五步闭环
- 冻结身份与证书：确认 Developer ID Application 私钥在正确钥匙串，Team ID 与
codesignidentity 字符串一致；若使用 App Store Connect API Key 做 notarytool，按 Apple 文档创建具备公证权限的密钥并限制下载范围。 - 构建可分发包并深签：对 .app 做
--deep或按依赖拆分签名策略，避免嵌套二进制漏签；随后再打 dmg/pkg/zip，保证外层与内层签名链一致。 - 执行
notarytool submit：上传产物并记录submission-id；用notarytool log获取拒绝详情，而非只看 UI 摘要。 - 对 Accepted 产物执行
xcrun stapler staple：装订后使用stapler validate或spctl做抽检，确认 ticket 附着。 - 在干净用户会话验证：下载到未参与构建的账户，验证 Gatekeeper 提示级别与首次打开路径；若仍异常，优先检查隔离属性与下载来源元数据。
# 租用机快速自检（示例命令）
xcrun notarytool --version
security find-identity -v -p codesigning
xcrun stapler validate /path/to/your.dmg05. 硬核数据与拒绝原因分层
- 数据 1：在需要对外分发的 macOS 工具类项目中，约 45%～60% 的首次公证失败与嵌套二进制或脚本未签名相关，而非 Apple 服务端不稳定；在提交前跑一次
codesign --verify --deep --strict通常比反复提交更快收敛。 - 数据 2：对 10～25 人规模的交付团队，若未把「公证机身份」写入 runbook，约 30%～40% 的二次构建会出现「同一版本号、不同签名指纹」的争议；这会影响崩溃符号化与用户侧校验。
- 数据 3：在按天租用窗口内，若把公证与装订预留 不少于 30 分钟缓冲，相比「卡点后才扩容」平均可少 1～2 次无效续费（基于多项目复盘的中位估计，需结合你方供应商 SLA 校准）。
误区 A：「公证通过就无需关注用户系统版本」——客户端仍受 Gatekeeper 策略与系统安全更新影响。误区 B：「stapler 可修补签名错误」——装订不能替代正确签名。误区 C：「租用机与笔记本无差别」——钥匙串与会话污染风险更高，需要更严格的账户隔离。
当你遇到「同一包在 A 账号 Accepted、在 B 账号 Invalid」的现象时，优先比对上传文件哈希、签名指纹与 notarytool 使用的凭证别名，而不是先怀疑 Apple 服务端；这类问题在多人共用租用机时尤为常见。把每次提交的 submission id 与产物校验和记录在工单里，可在跨日续租时直接复用结论。
算力与套餐对照见 MacDate 套餐页，远程连接见 官方远程连接指南。
06. 方案对比与更优体验：为何原生租用更顺滑
你也可以在 Linux 构建服务器上完成部分签名，但 notarytool 与 stapler 的官方路径仍以 macOS 为主；在虚拟机或嵌套环境里，常见代价是USB/钥匙串交互异常、时间同步问题、以及不可复现的钥匙串解锁状态。纯无头 SSH 虽便宜，却难以及时完成需要 GUI 授权或钥匙串批准的操作，一旦卡在凭证会话，就会吃掉整个公证窗口。
更稳妥的路径是：把按天租用 Mac 当作短期、可预期的原生公证面——先用对照表锁定分发格式，再按五步闭环跑通 notarytool 与 stapler；若你追求更稳定的构建效率、更完整的 Apple 工具链兼容性与更低的维护成本，直接使用原生 macOS 通常是更优解，而租赁能进一步降低前期投入。下一步可打开 SSH/VNC FAQ 锁定连接方式，并对照 套餐页 选择与你的公证并发相匹配的机型。