無自有硬件：在租用雲端 Mac 上完成提交、日誌、裝訂與 Gatekeeper 自檢的可復現 Runbook
当你要把 DMG、PKG 或命令行工具交给客户或同事「直接双击就能跑」，而你的主力机是 Windows 或 Linux、手边没有一台可随时开盖的 Mac 时，Apple Notarization（公证）往往成为最后一道门槛：它不只是上传一个 zip，而是一串对签名、Hardened Runtime、票据与装订（staple）的组合校验。更麻烦的是，许多失败并不会在第一次 notarytool submit 的退出码里完整展开，而是藏在 notarytool log 的详情 JSON 里；而另一类失败则来自钥匙串访问、开发者账号会话与系统时间这类「更适合在图形会话里目击」的环境问题。本文面向租用云端 Mac 的读者：先拆痛点，再给「仅 SSH / SSH+VNC / 以 VNC 为主」的决策矩阵，随后给出八步 Runbook、四条可写进变更单的结论，以及二十分钟同用户 VNC 验收表。文中与《首次使用清单》、《系统时间与证书核对》、《Fastlane Match 与 SSH/VNC》、《紧急小版本上架》互链，便于你把「能编译」与「能分发」放在同一工单里闭环。
在 App Store 體系之外分發 macOS 二進制時，Gatekeeper 與公證策略會把問題前移到構建機環境是否可信、簽名是否一致、是否有未聲明的敏感權限。租用的雲端 Mac 解決了「我沒有 Apple Silicon」的硬約束，但引入了四類常見工程痛點：（1）會話分裂——你在 SSH 裡用用戶 A 跑構建，在另一個會話裡用用戶 B 跑 notarytool，鑰匙串項與 Xcode 賬戶緩存看似都存在，實則不在同一安全域；（2）時間漂移——證書「尚未生效」類報錯在遠程機上比本地更常見，尤其在節點休眠、快照恢復或手動改過時區之後；（3）網絡路徑——企業出口或跨境代理會打斷對 Apple 公證服務的 TLS 長連接，表現為間歇 503 或握手超時；（4）租期與磁盤——公證產物與中間 zip 往往體積大，若未同步到對象存儲或你的主力機，容易在「租期結束 / 換節點」時丟失可復現證據。
誤以為「Accepted」就萬事大吉：對 DMG 等載體，若跳過 stapler staple 或未按 Apple 要求驗證裝訂結果，用戶側仍可能遇到「無法驗證開發者」或首次打開時的額外網絡回退。
日誌未存檔就反覆重傳：notarytool log 中的 UUID 與 issue 列表是排障第一現場，丟失會導致團隊在同一誤構建上循環浪費配額。
把公證與 App Store 上架混為一談：Organizer 上傳解決的是商店通道；公證解決的是商店外分發通道，二者憑證與失敗碼並不一一對應。
SSH 硬扛鑰匙串彈窗：沒有圖形會話時，部分憑證寫入看似成功，但後續批處理任務讀到的卻是空項或過期項。
忽略 Hardened Runtime 與 entitlements 邊界：公證拒絕裡大量是「啟用了不該啟用的能力」或「缺少必要聲明」，這類問題應回到 Xcode 構建設置而不是反覆改命令行參數。
未把「同用戶 VNC」寫進變更單：遠程團隊扯皮時，最常見的一句話是「我這邊明明能跑」——本質是沒有把用戶、會話與監聽端口釘死在同一張證據表上。
| 步驟 / 證據 | 僅 SSH | SSH 構建 + VNC 收尾 | 全程同用戶 VNC 主導 |
|---|---|---|---|
| Archive / 導出簽名的 .app | 通常可行 | 可行 | 可行，適合新手目擊每一步 |
| 創建 zip / 提交 notarytool | 可行 | 可行 | 可行 |
| 輪詢 notarytool info / log | 可行 | 可行 | 可行 |
| 鑰匙串訪問 / Apple ID 會話 / 2FA | 高風險 | 推薦 | 推薦 |
| 裝訂 stapler staple 與本地 spctl 自檢 | 部分可行 | 推薦 | 推薦 |
| 向非技術同事「演示為什麼不過」 | 弱 | 強 | 最強 |
这张表刻意把「命令能不能跑」与「证据能不能被第三者复现」拆开：对独立开发者而言，很多时候混合路径性价比最高——编译与压缩在 SSH 里完成，涉及账户、钥匙串与「第一次装订结果」的确认，则切到与构建同一用户的 VNC 桌面会话里完成。这样你既保留脚本化流水线，又避免在排障阶段陷入「终端里看不见弹窗」的黑盒状态。若你完全零基础，则建议直接以 VNC 为主，把首次清单里的连接、剪贴板与分辨率设置先跑通，再进入公证命令链，否则会在第一步就被「无法把 zip 拷到正确目录」这类低级问题消耗半天。
公證鏈上的硬通貨只有兩個：UUID + 日誌 JSON，以及同用戶鑰匙串裡可驗證的憑證。
冻结指纹：在工单首行写下 sw_vers、xcodebuild -version、notarytool 版本、节点租约 ID；若你刚处理过时钟问题，交叉引用系统时间表把「自动设定日期与时间」截屏存档。
确认签名链：对将要提交的 .app 使用 codesign -dv --verbose=4 与 spctl -a -vv 做本地预检；若团队使用 Match，先对照Match 文确认描述文件与钥匙串 bootstrap 在同用户下完成。
製作可提交工件：按 Apple 要求打包 zip（注意符號鏈接、擴展屬性與深層目錄）；大體積工件建議先計算 SHA256 寫入變更單，避免傳輸後半包。
提交：notarytool submit ./Your.zip --apple-id ... --team-id ... --password ... --wait 或拆分「提交 + 輪詢」；把返回的 submission id / UUID 原樣粘貼到工單附件。
拉取日誌：對非 Accepted 狀態，立即執行 notarytool log <submission-id> 並保存 JSON；不要在未讀日誌的情況下改 entitlements 盲重傳。
修復構建問題：若日誌指向 hardened runtime、沙箱或簽名不一致，回到 Xcode 構建設置與 Archive 產物重新導出，而不是僅重打外層 zip。
裝訂：對需要 staple 的載體執行 xcrun stapler staple，隨後用 stapler validate 或 Apple 文檔推薦的驗證步驟確認票據附著。
烟测与归档：在干净用户或另一台 Mac 上做最小双击打开测试；把最终 DMG、日志 JSON、命令行输出与 stapler 结果打包进版本库旁的 release 证据目录。若你同时在做紧急上架，可把本步与热修手术室文的 Organizer 段落交叉执行，但注意商店通道与公证通道的凭证不要混用同一套「临时口令」。
xcodebuild -version notarytool --version codesign -dv --verbose=4 "Your.app" ditto -c -k --keepParent "Your.app" "Your.zip" notarytool submit "Your.zip" --apple-id "$APPLE_ID" --team-id "$TEAM_ID" \ --password "$APP_SPECIFIC" --wait notarytool log "$SUBMISSION_ID" > notary-log.json xcrun stapler staple "Your.dmg" xcrun stapler validate "Your.dmg"
上述命令中的環境變量命名僅作示例：生產環境應使用 CI 密鑰管理或 xcrun notarytool store-credentials 一類「不在 shell 歷史裡明文回放」的方式；在多人共用租用節點時，還要額外約定誰有權旋轉 App 專用密碼，並把旋轉事件記入與 Match 倉庫同級的審計日誌。若你在遠程機上同時跑自動化與手工公證，建議把「提交 zip 的目錄」與「日常開發 DerivedData」分盤或分路徑，避免誤把調試符號或未剝離調試器的構建混進提交包——這類錯誤在日誌裡常表現為體積異常或簽名嵌套不一致，排障時優先對照 Archive 配置而非網絡層。
當日志提示與網絡相關時，不要立刻懷疑 Apple 服務端：先在 VNC 會話裡打開「網絡實用工具」或最小 curl -v 驗證 TLS 握手，再核對企業代理是否對長連接做了中間斷開；若你使用分流策略，確保 notary 流量沒有誤走需要人機二次認證的代理頁。對於要在多個地理區域分發的團隊，還應記錄「公證提交地」與「目標用戶主要時區」，以便在偶發區域性故障時快速判斷是否屬於局部網絡問題而非構建缺陷。
| 核對項 | VNC 側證據 | SSH / 終端證據 | 通過標準 |
|---|---|---|---|
| 用戶一致 | 菜單欄顯示的用戶名與工單一致 | id -un 與構建腳本一致 | 無 sudo 混跑 |
| 時間與 TLS | 日期與時間面板截圖 | sntp / curl -I 關鍵頭 | 與 NTP 表一致 |
| 提交成功 | （可選）瀏覽器僅用於讀文檔 | submission id 行 | UUID 已存檔 |
| 日誌無未關閉 issue | 打開 JSON 目視關鍵字段 | jq 過濾 issue 數組為空 | Accepted 且可複驗 |
| 裝訂與驗證 | 雙擊 DMG 煙測錄屏（可選） | stapler validate 輸出成功 | 離線打開無額外警告 |
这张表的价值在于把「时间戳对齐」写进习惯：当你向客户解释「为什么昨晚的包今天才可用」时，submission 时间、装订时间与 NTP 截图能构成一条短证据链，避免口头扯皮。若团队并行维护多条产品线，还应把「产品 bundle id + 公证 UUID」做成可检索索引，而不是散落在个人下载目录里。对于需要长期保存的日志 JSON，建议同步到你方对象存储并设置保留周期，与租用节点的磁盘清理策略解耦——否则很容易在磁盘清理类操作中被误删。
本文不替代 Apple Developer Documentation 對 notarytool flags 的逐項說明——那些應以發行版為準；此處專注租用遠程 Mac 場景下的證據鏈與 VNC 強制步驟。若你還同時在跑 iOS 上架流水線，請把公證與 Organizer 上傳拆成兩張變更單，以免在憑證輪換窗口把 App 專用密碼與商店會話混在一個密鑰桶裡。
對常見 DMG/ZIP 分發，裝訂能顯著改善離線雙擊體驗；具體載體是否必須裝訂請以 Apple 當前文檔為準，並在變更單記錄 validate 結果。
提交與輪詢通常可以；涉及鑰匙串、賬戶會話或需要目擊彈窗時，應切到與構建同用戶的 VNC。
時間漂移、代理打斷、租期回收與多用戶鑰匙串域不一致；先用本文第五節表做快檢再讀日誌。
固定 submission id，完整保存 notarytool log JSON，再對照簽名與 entitlements；避免盲重傳。
把公證鏈放在工程視角下審視時，你會發現真正的成本不在「多等幾分鐘上傳」，而在證據是否能在第三臺機器上被複現：同用戶鑰匙串、可檢索的 UUID、可 diff 的日誌 JSON，以及裝訂後可通過 validate 的載體。純 SSH 的租用節點非常適合腳本化構建，但一旦進入「賬戶會話 + 鑰匙串 + 用戶雙擊體驗」的交界，繼續堆遠程命令往往不如開一條可圖形登錄的 macOS 會話來得便宜——這與我們在多篇 Xcode / 證書長文裡反覆強調的 VNC 價值是同一結論。
自有 Mac 路線則要求你自己承擔硬件折舊、辦公室出口帶寬、以及「誰坐在屏幕前點授權」的排班成本；對以 Windows 為主力機、只在發版周需要 macOS 的團隊來說，這些隱性成本常常比按小時租機更難預測。相比之下，租用帶 Apple Silicon 的遠程 Mac可以把在線率與基線鏡像交給專業服務商，同時保留你對簽名與公證命令鏈的控制，並把 notarytool log 與系統設置裡的時間、網絡項放在同一桌面會話裡對齊。
若你需要一臺便於完成本文第五節同款同用戶 VNC 驗收的遠程 Mac，可通過 VNCMac 下單：主按鈕進入中文站購買頁；連接方式與 SSH-VNC 說明見幫助中心。