分發節點 · 專用簽署機 · Provisioning 輪轉 · Keychain 邊界 · 決策矩陣
行動端與平台工程負責人在多台遠端 Mac 組成 mesh 時，常遇到「這台 Archive 能簽、那台 CI 報 Provisioning 不相符」：描述檔輪轉視窗沒對齊、分發憑證被複製進共享碟，或每個 Runner 各自匯入 p12 導致 Team 內容脈絡漂移。本文給出單點簽署機、每節點獨立憑證、受控分發三種拓樸對照、Provisioning 與 Bundle ID 對應的輪轉與冪等等定、六步可重現落地與規模 × 合規 × 發布頻率決策矩陣；並與Golden Image 與環境漂移、共享建置池 Runner、OIDC 憑證分倉互鏈，便於把簽署內容脈絡與工具鏈批次一次對齊。
你已依Golden Image 清單把 Xcode 批次釘住，卻仍會在 mesh 裡看到 errSecInternalComponent 或 Provisioning 不相符。根因往往是簽署內容脈絡未當成一等公民納入流水線後設資料：描述檔 UUID、Team ID、憑證指紋與鑰匙圈作用範圍必須與 IMAGE_ID 同樣可稽核。與共享建置池組合時，若 Runner 可任意匯入 p12，合規與排錯會同時失控。
Profile 輪轉視窗：Apple Developer 後台更新描述檔後，舊 UUID 仍在部分節點快取，表現為隨機節點失敗；需要顯示版本號檔案而非「下載最新」。
分發憑證擴散：同一 .p12 被 scp 到多台 mesh 節點，撤銷一次即全域停擺，且稽核無法回答「誰在哪台機器匯入了私密金鑰」。
鑰匙圈作用範圍混亂：login 與 System keychain、以及 CI 使用者的鑰匙圈解鎖策略不一致，導致 headless 下偶發找不到身分。
多 App ID 對應錯誤：Extension 與主 App 使用不同 Provisioning，卻在 xcodebuild 參數裡寫死單一 PROVISIONING_PROFILE_SPECIFIER。
與產物快取混排：把 profile 與 DerivedData 放在同一「可清理」目錄，被清理指令碼誤刪後表現為「昨晚還能簽」。
把以上五條寫進 on-call 說明文件的「先查簽署層再查編譯層」順序，能顯著減少跨區 mesh 下的無效重試。接力場景下的人機互動延遲還會放大等待視窗，可與SSH 與 VNC 對照一起評估「誰有權在簽署機上點允許」。
沒有「最正確」的拓樸，只有與撤銷半徑、合規稽核與 mesh 彈性是否匹配。單點簽署機撤銷面最小但存在單點排隊；每節點獨立憑證彈性最好但稽核最貴；受控分發折中，需要嚴格的 profile 清單與唯讀掛載策略。與OIDC 憑證分倉類比：私密金鑰材料也應滿足「最短存活、最小暴露面」。
| 維度 | 專用簽署機 | 每 Runner 獨立憑證 | 受控分發（清單 + 唯讀） |
|---|---|---|---|
| 撤銷半徑 | 最小；一次輪換影響面可控 | 最大；需逐台追蹤 | 中；依賴清單版本號 |
| 佇列與 mesh 彈性 | 易瓶頸；需預約或側車匯出 | 高併發友善 | 中高；profile 可並行拉取 |
| 合規稽核 | 最易；存取與匯出可記錄 | 難；私密金鑰散落多機 | 中；需證明無人手改掛載層 |
| 與 Golden Image 關係 | 簽署機可獨立批次 | 憑證與映像批次易脫鉤 | profile 版本應寫進映像後設資料旁路 |
| 常見反模式 | 把簽署機當通用編譯機 | 把 p12 提交進製品庫 | 用「最新 profile」語意拉取 |
簽署治理是否合格，取決於「一次撤銷能否在分鐘級解釋清楚影響了哪些節點與哪些流水線」，而不是「平時能不能編過」。
若 mesh 中同時跑 Archive 與 PR 建置，請把簽署動作與編譯動作在佇列維度拆開計費與租約；與共享池席位鎖聯用時，避免「佔著編譯鎖卻在等人工點鑰匙圈允許」。
下面六步可與Golden Image 六步並行執行：映像管工具鏈，本文管簽署材料與鑰匙圈邊界。每一步都應有可稽核的變更單號；與共享池租約組合時，簽署機領取席位應獨立於編譯佇列。
凍結 profile 清單：在儲存庫或受控桶保存 profiles.json（UUID、檔名、過期日、Team ID），CI 入口檢核與節點掛載一致。
宣告簽署拓樸：在 README 寫明採用專用機／分發／每節點，並列出允許存在私密金鑰的 hostname 清單。
鑰匙圈與解鎖策略：為 CI 使用者建立專用鑰匙圈分區，寫入說明文件 security unlock-keychain 的時限與失敗回退。
匯出動作閘門：任何 .p12 匯出必須雙人覆核＋工單號，禁止「臨時匯出放桌面」。
節點探針擴充：在工具鏈指紋之外追加 security find-identity -v -p codesigning 摘要雜湊寫入日誌索引。
輪轉演練：在預發池模擬 profile 過期前 7 天視窗，驗證新舊 UUID 並行期與回滾順序。
export PROFILE_MANIFEST_SHA="$(shasum profiles.json | awk '{print $1}')"
export SIGNING_SUMMARY="$(security find-identity -v -p codesigning | shasum | awk '{print $1}')"
node scripts/assert-signing-context.mjs \
--expect-manifest "${PROFILE_MANIFEST_SHA}" \
--expect-signing "${SIGNING_SUMMARY}" \
--region "${RUNNER_REGION}"
提示：探針輸出只進日誌索引，不要把私密金鑰指紋寫進公開製品後設資料；對外 SBOM 使用憑證序號後六位或內部別名即可。
mesh 下最常見的假陽性是主 App 已更新 profile、Extension 仍指向舊 UUID。排錯順序：先比對 embedded.mobileprovision 與建置參數，再比對鑰匙圈身分摘要，最後才懷疑 Xcode 專案設定。與可觀測任務鏈聯用時，把 profile_manifest_sha 寫進 handoff 信封。
蒐集證據三元組：codesign -dvvv 輸出中的 Team、Authority 與 Sealed Resources。
比對 profile 清單：失敗節點與成功節點的 profiles.json 雜湊是否一致。
檢核鑰匙圈解鎖視窗：是否落在無人值守時段導致首次簽署失敗。
檢查多 target 對應：每個 target 的 CODE_SIGN_STYLE 與 specifier 是否成對一致。
核對匯出 IPA 管道：Archive 與 adhoc 是否共用錯誤 profile 目錄。
寫回冪等鍵：在佇列完成事件裡附帶本次使用的 manifest 版本，避免下游重複簽。
注意：不要在並行視窗內混用「自動管理簽署」與顯示 profile 檔案路徑；混用會在 mesh 上表現為「僅部分 target 偶發失敗」。
下列三條為跨區 iOS 工程化常見立案核對區間，請用你們自己的統計替換；保留樣本來源以便稽核。
| 團隊規模 | 合規等級 | 發布頻率 | 更穩的第一選擇 |
|---|---|---|---|
| 小團隊 | 標準 | 每週多次 | 專用簽署機＋顯示 profile 清單；禁止共享 p12 |
| 中型團隊 | 標準 | 每日多次 | 受控分發＋節點唯讀掛載＋輪轉自動化 |
| 平台化團隊 | 高 | 持續交付 | 硬體安全模組或等價側車＋全量稽核索引 |
| 多外包協作 | 中 | 不規則 | 隔離 Runner 池＋每專案獨立 profile 前綴 |
用個人筆電兼做簽署機會帶來休眠、系統更新與不可稽核的鑰匙圈點選；自建機房 Mac 則受採購與多地同步拖累。相較之下，合約 SLA 清楚的遠端 Mac 節點更適合承載 mesh 中的「簽署閘門」角色。
常見誤區：把「codesign 偶發成功」當成 profile 沒問題；應在探針層強制比對 manifest 雜湊。
若既要跨區 mesh 又要把簽署材料收斂到可稽核邊界，純靠口頭規範很難長期維持；借用零散裝置則幾乎無法證明「私密金鑰從未離開受控區」。對需要可重現簽署與穩定門檻 的場景，VpsMesh 的 Mac Mini 雲端租用通常是更優解：區域與規格可選、節點可專用、便於把簽署機與編譯 Runner 在合約與維運上拆開，讓 mesh 策略落在可驗收條款而不是個人習慣。
在流水線寫入 profile 版本號與過期日門檻，新舊 UUID 並行視窗內以顯示檔名引用；編排側可與共享建置池 Runner長文中的冪等欄位對齊。需要隔離簽署機時可參考訂購頁。
先用Golden Image 與環境漂移凍結工具鏈批次，再回到本文處理憑證與 profile 對應；價格與規格可對照價格頁與三年 TCO 長文。
連通與遠端開發條目見說明文件；接力與延遲基線見SSH 與 VNC 對照長文；profile 異常時優先核對本文第三節探針與 manifest 雜湊。