2026 年遠端 Mac 經 SFTP/rsync 同步建置產物時，如何治理 .DS_Store、.AppleDouble 與 ._* 資源分叉：排除規則、--delete 誤刪風險與唯讀發佈錨定的決策矩陣
遠端 Mac 到 Linux Runner 的目錄同步裡，._*、.DS_Store 與 --delete 組合常被低估：根因多在寫入面與刪除半徑未寫進變更單。本文給出排除模板、帳號拆分、staging 閘門順序，並聯《APFS 延伸屬性》《files-from》《原子發佈》《quarantine》。
2026 為何「多幾個小檔」仍值得寫進事故覆盤
痛點一：資源分叉在非 Mac 上成為 ._* 與 .AppleDouble，進入簽章與掃描路徑後放大不確定性。
痛點二：.DS_Store 讓目錄級 delta 抖動，容量與告警失真。
痛點三：--delete 與去噪目標衝突，易誤刪對端檔案。
痛點四：與 APFS xattr 完整性混排時排障跳躍浪費 on-call。
痛點五與六：互動式 SFTP 與 CI 共用可寫金鑰時，拖放會引入雜訊且難稽核；閘門只校大包雜湊而忽略目錄項仍可能在公證階段失敗。
- 將 Finder 中繼資料與建置產物拆到不同子樹；發佈錨禁止人工拖放除錯素材。
- 啟用
--delete的 Job 必須綁定 staging 路徑常數並雙人覆核。
決策矩陣：排除、清單與唯讀錨
目標在壓縮刪除半徑與寫入面。小團隊先排除＋staging；目錄複雜用《files-from》；對外唯讀視圖用錨＋軟連結。
| 策略 | 適用邊界 | 典型誤用 | 站內銜接 |
|---|---|---|---|
| 排除模板 | 穩定樹、雜訊可枚舉 | 排除漂移、delete 誤傷 | bwlimit 文 |
| manifest | 複雜產物樹 | 清單不穩 | files-from |
| 唯讀錨＋帳號拆分 | 人機/CI 隔離 | 唯讀標籤但金鑰過寬 | 原子發佈 |
| xattr 完整性 | 需保留標籤 ACL | 雜訊與 xattr 混淆 | APFS xattr |
How-to：排除、staging、閘門
下列為可稽核骨架，請替換主機與路徑。
rsync -az \\
--exclude='.DS_Store' \\
--exclude='.AppleDouble' \\
--exclude='._*' \\
--delete \\
./staging/out/ user@runner:/data/in/- 凍結路徑常數：發佈錨、staging、Runner 寫入單一參數表。
- 刪除面：
--delete僅 staging；推拉模板分離。 - 排除基線：含 IDE 快取目錄。
- dry-run：三次比對刪除與傳輸條目。
- 帳號拆分：人類可寫協作樹；CI 唯讀錨。
- 閘門：manifest 或 SHA256 通過後再切換可見性。
純 SFTP 工具鏈稽核粒度常弱於 rsync filter，更依賴唯讀錨與清單。
實務上建議在值班手冊寫明：先確認 delete 開關與作用域，再比對排除模板版本，最後才懷疑磁碟或網路；可把常見日誌指紋附在附錄以降低跨團隊溝通成本。
變更單欄位（誤刪半徑與雜訊計數）
每次同步至少記錄四元組：排除模板版本、._* 與 .DS_Store 計數、delete 作用域、閘門摘要（manifest 或大包 SHA256 與失敗樣本路徑）。數值依鏈路複測，欄位齊全才有助覆盤。
伺服器側分層
在 macOS 上分三層：人類協作、建置工作、發佈錨；CI 只掛載唯讀錨。sshd Match 與稽核請併讀站內併發與稽核專文。
產物若需本機驗證，quarantine 與簽章鏈請併讀專文。
站內互鏈
順序：排除模板 → files-from → APFS xattr → 原子發佈；物件儲存兩段式請讀站內對應文。
FAQ
問：一條超長 exclude？答：短期可行，長期會漂移；應版本化並監控雜訊計數決定是否升級 manifest。
問：Linux 刪掉 ._ 後又出現？答：源端仍在產生，請治理寫入路徑而非只刪目標端。
問：tar 與 rsync？答：跨平台且重視權限與資源叉時 tar 常較穩；請對照 APFS xattr 矩陣。
總結與遠端 Mac 託管收束
本文將 .DS_Store、.AppleDouble 與 ._* 視為跨平台同步的可控變數，決定 delete 半徑、增量穩定度與閘門可信度。自建遠端 Mac 在權限矩陣與值班文件上持續耗力。
若要把「建置真相源＋傳輸入口＋發佈錨」收斂到可合約化的服務平面，託管遠端 Mac可降低目錄漂移與併發對齊的人耗：團隊專注交付與簽章視窗。
請參考 SFTPMAC 首頁方案 與說明中心，把遠端 Mac 當成「像 SFTP 一樣可控」的長期節點。