三類痛點：為什麼「傳完」仍可能在發佈後才爆雷
痛點 1：靜默位元錯誤與跨檔案系統時間戳。預設 rsync 以大小與 mtime 作為「是否需要重傳」的主要啟發式；當建構機與遠端 Mac 分屬不同檔案系統、或 NFS／容器層導致時間戳精度被截斷時，可能出現跳過實際已損毀檔案的假陰性。對含數千小檔案的 dist 目錄，此假陰性會在 CDN 或簽章校驗階段才暴露，排查成本指數級上升。
痛點 2：斷線與半包。大檔上傳中斷後若未以 --partial-dir 隔離暫存，恢復時目錄可能處於不可宣告一致狀態；CI 重試亦會與殘留交錯，必須把批次號寫入稽核，不能只看最後一次離開碼。
痛點 3：SFTP 側無法回答「誰寫了什麼」。多人共用同一寫入帳號、或圖形用戶端未記錄操作者時，伺服器日誌僅能看見認證成功與位元組數，難以對應到具體發佈批次。與多租戶隔離及併發預算搭配時，若缺少依流水線拆金鑰與依目錄打標籤，稽核欄位會長期空白，合規抽查亦難過關。
為何 2026 年仍不能把「mtime＋size」當作完整性證明
mtime／size 是元資料近似，不是內容充分條件：touch 統一時間戳、解壓改寫權限、同大小占位檔等均可造成假陰性。強交付鏈路應在里程碑使用摘要：要么 rsync --checksum（CPU 較貴），要么流水線產生 manifest 並在遠端 shasum -c 硬閘門；後者較易配合原子發佈：先校驗 releases／批次 再切 current。SFTP 與 rsync 對符號連結與延伸屬性的預設處理不同，須在規範中固定 flags，manifest 僅列業務相關檔案，避免誤報。
決策矩陣：全量 checksum、獨立 SHA256 清單與發佈後抽檢
下表協助在 CPU、時間與風險間做顯式取捨；可與團隊 SLA 對齊後寫入儲存庫規範。
| 策略 | 適用情境 | 主要成本 | 失敗時可觀測性 |
|---|---|---|---|
rsync --checksum（-c） | 目錄中等、CPU 充裕、希望單命令閉環 | 兩端全檔雜湊掃描，大目錄可能數倍延長 | 同步日誌可見跳過／重傳原因 |
建構端 manifest＋遠端 shasum -c | CI 已產生產物包、需與發佈閘門腳本統一 | 維護 manifest 產生與路徑正規化 | 非零離開碼直接阻斷切鏈，易整合 Slack／郵件 |
| 發佈後抽檢＋監控 | 極大儲存庫、全量校驗不可行 | 仍有低機率漏檢，需抽樣設計 | 依賴線上探針與簽章比對，延遲可能以小時計 |
| 僅 size／mtime（預設 rsync） | 內網千兆、信任域極高、臨時同步 | 最低 | 最差；不建議作為生產發佈主路徑 |
實作：rsync 斷點、頻寬與 CI 校驗閘門（至少五步）
下列命令須於測試環境驗證後再用於生產；將 deploy@remote-mac 與路徑替換為你的遠端 Mac 或託管節點。與原子發佈結合時，目標應為版本目錄而非直接覆寫對外路徑。
# 步驟 1：在建構端產生 SHA256 清單（示例：dist 目錄）
cd dist && find . -type f -print0 | sort -z | xargs -0 shasum -a 256 > ../manifest.sha256
# 步驟 2：帶斷點與部分目錄的 rsync（降低半包污染目前目錄）
rsync -avP --partial --partial-dir=.rsync-partial \
--bwlimit=8000 \
-e "ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=6" \
./ ../manifest.sha256 \
deploy@remote-mac:/srv/app/releases/202603281200/
# 步驟 3：遠端執行校驗閘門（非零則禁止切鏈）
ssh deploy@remote-mac "cd /srv/app/releases/202603281200 && shasum -a 256 -c manifest.sha256"
# 步驟 4：通過後記錄稽核批次（示例：寫入 JSONL）
ssh deploy@remote-mac "echo '{\"ts\":\"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'\",\"batch\":\"202603281200\",\"gate\":\"shasum\",\"exit\":0}' >> /var/log/ci-publish-audit.jsonl"
# 步驟 5：再執行 ln -sfn 或等價原子切換（參見原子發佈專文）
# ssh deploy@remote-mac "ln -sfn /srv/app/releases/202603281200 /srv/app/current"
若必須以純 SFTP上傳，仍可在上傳結束後於遠端以同一份 manifest.sha256 校驗；關鍵是不要讓圖形用戶端在校驗前對生產路徑做 in-place 覆寫，而應寫入 releases 子目錄，與符號連結發佈模型一致。
可引用資料：閘門閾值、磁碟與稽核保留週期
基線建議：（1）空閒空間 ≥ 單次封包2.5 倍（斷點檔、上一版、manifest）。（2）CI 逾時 ≥ P95 同步耗時三倍；300MB 級跨國常見 45–180 秒。（3）稽核含流水線 ID、提交 SHA、批次目錄、校驗離開碼、主體；保留 ≥ 90 天。（4）啟用 --checksum 後記錄首次全量基線耗時。寫入帳號僅寫 releases/*；唯讀帳號讀 current。與Chroot 組合時可限制 CI 僅單一前綴。
FAQ、內鏈收束與為何考慮租賃遠端 Mac
斷點續傳目錄要提交到 Git 嗎？
否。.rsync-partial 應加入 .gitignore；僅在發佈機保留，供傳輸中斷後安全恢復。
manifest 與 npm／yarn 鎖檔有何關係？
鎖檔約束相依版本；manifest 約束建構產物位元組級輸出。二者互補，不能互代。
何時必須上獨立校驗閘門而非僅依賴 rsync 離開碼？
當產物用於簽章校驗、App 商店上傳或付費客戶交付，且鏈路含公網或多跳代理時，應在切流量前執行 shasum -c 或等價步驟。
自建與租賃遠端 Mac均可復現上述流程；自管需承擔磁碟告警、金鑰輪換與頻寬抖動。發佈頻次升高時，把隔離目錄與 SFTP 准入交給託管可省救火時間。SFTPMAC 支援在受控目錄內繼續使用斷點、SHA256 閘門與符號連結模型。建議預發先跑通「同步 → 校驗 → 切鏈」再切生產。
若希望減少自管遠端 Mac 的磁碟、權限與在線率問題，把 SFTP 准入與目錄隔離交給專業託管，同時繼續以 rsync 與校驗閘門保障產物完整性，可了解 SFTPMAC 的套餐與節點選型。