症狀：不同信任等級的 Mac CI 工作共用快取寫入能力，難以判斷誰能改變後續建置所讀取的資料。
最快解法：用 GitHub Actions cache-mode 按工作流程或 Job 限制快取讀寫；Job 層設定優先，低信任事件先採取最小必要權限，再用實際執行結果驗證。

這適合維護 Apple 平台工作流程、需要區分快取讀寫權限的開發者。
如果你負責倉庫安全，或管理多個 Apple 專案的 CI，本文也會說明如何檢查權限繼承與留下審計紀錄。

最後更新於 2026 年 9 月 28 日；設定規則核對自 GitHub cache-mode 發布公告及官方工作流程語法文件。

GitHub Actions cache-mode 的判斷重點是任務需要什麼權限

GitHub 已說明 cache-mode 可在工作流程或 Job 層級管理快取存取，且 Job 層設定會優先於工作流程層設定；發布公告亦指出此功能適用於所有方案。這代表你可以按任務設權，而不是把整個 Apple 專案的每個工作都當成同一種信任等級。官方公告

實務上，先分清三種需求：只需要還原快取、需要儲存快取，或根本不應存取快取。以下矩陣說明選擇原則；實際設定名稱及語法請依照 GitHub 官方文件，不要把表中的說明文字直接當作 YAML 欄位值。

任務類型 快取需求 權限選擇原則 驗收證據
可信任分支的常規建置 還原並保存快取 只在確實需要時允許寫入 執行紀錄顯示預期的還原與儲存行為
外部貢獻者提交的檢查 通常只需讀取，或完全不使用快取 不給不必要的寫入能力 檢查快取日誌，確認未出現非預期的保存
只執行格式檢查或輕量驗證的工作 可能不需要快取 關閉不需要的存取 工作仍能完成，且沒有快取存取紀錄
發佈或更新快取的受控任務 可能需要保存 限定在明確授權的任務範圍內 權限與任務目的相符，且保存位置可追溯

GitHub 的依賴快取安全說明提醒，快取可能跨工作流程被還原；能寫入快取的程式碼可能影響後續任務取得的內容。因此，快取寫入不是單純的速度選項，而是信任邊界的一部分。

工作流程與 Job 設定要分開核對

Job 層的 cache-mode 會不會蓋過工作流程設定？
會。官方文件指出，Job 層級的設定優先於工作流程層級設定。工作流程層適合設為一般基準；若某個 Job 的信任條件或快取需求不同，再在 Job 層明確收緊或指定模式。檢查時不要只讀最外層設定，還要逐個核對實際執行的 Job。工作流程語法文件

設定位置 適用目的 需要檢查的項目 不通過時的處理
工作流程層級 為整份工作流程提供一致的預設 是否有明確設定，是否適用所有工作 改成符合多數任務的最低權限基準
Job 層級 讓個別任務使用不同權限 是否覆蓋上層設定，是否與觸發來源相符 移除多餘寫入權，或拆分不同信任等級的 Job
可重用工作流程 在呼叫端與被呼叫端之間傳遞權限邊界 呼叫端實際授權、被呼叫端的 Job 設定 由呼叫端縮小授權，再驗證呼叫結果

驗收不能停在閱讀檔案。把設定檢查與執行紀錄放在一起比對：工作流程層是否套用到預期範圍、個別 Job 是否覆蓋基準、日誌呈現的快取行為是否符合設定。若只有建置成功，不能據此推定權限正確。

低信任觸發事件不能預設取得寫入能力

pull_request_target 工作流程應該開放快取寫入嗎？
不能只因為某個工作流程需要快取，就直接授予寫入權。先檢查觸發事件如何取得程式碼、哪些步驟會執行外部提交內容，以及這些步驟是否能影響快取。GitHub 對安全使用 pull_request_target 有專門警告：若工作流程以不安全方式執行不可信程式碼，可能擴大攻擊面。安全使用 pull_request_target 的官方說明

快取權限收緊有助於減少不可信程式碼寫入共用快取的機會，但不等於整份工作流程已安全，也不能保證完全消除快取投毒。若工作流程還會取得機密資料、使用具寫入能力的憑證，或執行外部動作，仍須另外檢查這些權限與程式碼路徑。GitHub Actions 安全使用指南

注意：不要以「快取命中」作為權限驗收結果。命中只表示有可還原的快取資料，不代表寫入來源可信，也不能證明 Job 層級的規則確實生效。

可重用工作流程不能突破呼叫端的授權範圍

可重用工作流程會繼承呼叫端的快取權限嗎？
要檢查呼叫端實際授予的權限，以及被呼叫工作流程內部的設定。依官方規則，被呼叫的工作流程不能取得高於呼叫方授予的快取權限；但如果呼叫端已給得過寬，重用並不會替你自動縮小風險。可重用工作流程官方說明

驗收面向 通過時的證據 不通過時的收緊動作
呼叫端授權 呼叫端只授予完成任務所需的快取權限 先縮小呼叫端授權，再測試被呼叫流程
被呼叫工作流程 Job 層設定沒有不必要的寫入權 將不同用途拆成不同 Job，分別設定
實際執行結果 執行日誌與設定模式一致 暫停推廣，使用受控測試工作流程重現
快取管理紀錄 能追查建立、還原或刪除的快取項目 依快取管理文件檢查快取項目及清理方式

用六個步驟驗收 Mac CI 快取權限

以下流程把權限檢查、快取行為與 Xcode 建置結果拆開。這樣能避免把建置速度變快、快取命中，或工作流程成功誤判為權限設定正確。

  1. 盤點工作流程與觸發來源。 列出一般分支建置、外部貢獻者檢查、發佈任務及可重用工作流程，標記每個任務是否會執行不可信程式碼。
  2. 逐個 Job 寫明快取目的。 說明它只需還原、需要保存，或不應存取快取；沒有明確理由的寫入需求先移除。
  3. 核對設定層級與正式語法。 檢查工作流程層的基準設定，再找出所有 Job 層設定；依照工作流程語法文件採用正式語法，不要從別人的範例推測欄位名稱。
  4. 單獨審查低信任事件。 對 pull_request_target 等觸發方式，確認程式碼來源、執行步驟與快取寫入能力之間的關係；若無法排除不可信程式碼影響快取，就取消寫入或停用該工作流程的快取存取。
  5. 在受控倉庫驗證三種結果。 分別確認預期的快取還原、快取保存與不存取行為；檢查執行紀錄後，再獨立確認 Xcode 建置或其他 Apple 平台測試是否通過。
  6. 記錄跨倉庫推廣與回滾條件。 保存權限理由、測試情境、核對過的工作流程版本，以及不符預期時如何恢復先前設定。先在代表性倉庫驗證，再依團隊審核流程推廣。

GitHub 的快取管理文件可協助你檢視快取項目；但它不能取代工作流程權限驗收。快取有命中紀錄、建置有輸出，仍需回頭確認觸發事件、Job 設定與實際存取行為彼此吻合。

推廣前以評分判斷是否可放行

指標 通過 需修正 暫停推廣
最小權限 每個 Job 都能說明為何需要還原或保存 少數 Job 的用途不清楚 低信任程式碼仍可寫入共用快取
設定優先序 上層與 Job 層設定及預期一致 有覆蓋設定但未記錄原因 無法確認執行時套用哪個設定
執行證據 快取日誌、設定與建置結果分開核對 只有建置成功紀錄 權限行為與設定不一致，或無法重現
可回復性 有負責人、回滾設定與追蹤紀錄 回滾方式未經驗證 推廣後無法快速撤回過寬權限

建議只有在最小權限、設定優先序與執行證據都通過時才擴大部署；任何一項仍未核實，就先保留在受控倉庫，不要以快取命中率或建置耗時代替安全驗收。

若你的現有做法是讓所有 Mac CI 任務共用寫入權，或在主力 Mac 上手動重跑驗證，缺點是權限邊界模糊、重現條件難以固定，也容易把快取行為與 Xcode 建置問題混在一起。需要臨時驗證 Apple 專案工作流程時，SSHMac 的 Mac 租用環境可作為與主力設備分開的測試選項；開始前可透過SSHMac 使用協助中心確認遠端使用與支援資訊，也可查看SSHMac 的 Mac 環境選項，再按工具鏈、實體介面需求與使用週期決定。若工作負載長期穩定且持續高負載，自購設備可能更合適；若必須連接特定實體裝置，也應先確認遠端環境能否滿足。租用 Mac 只能提供測試環境，不能取代快取權限與工作流程安全審查。