三類典型痛點：為何發佈視窗總在看不見的地方翻車
痛點 1：一致性視窗（讀寫交錯）。以圖形化 SFTP 或腳本逐檔覆蓋時，線上目錄在數秒到數分鐘內處於「一半新一半舊」；CDN 或快取若分別快取了索引頁與靜態資源的不同版本，會出現樣式錯亂或簽章不符。
痛點 2：失敗重試與未知中間態。上傳中斷後難以斷言哪些檔案已完整寫入；沒有版本化目錄時，回滾常變成再解一層備份壓縮檔，視窗被拉長。
痛點 3：權限與稽核難落地。共用同一 SFTP 帳號寫正式目錄時，日誌只能看到「有人寫了目錄」，無法對應到具體發佈批次；與 CI 共用金鑰時，輪換會一次影響所有環境。
為何 2026 年直接 SFTP 覆蓋正式目錄仍是高風險路徑
並非 SFTP 協定落後，而是 in-place 覆蓋 與 原子切換 語意不同：前者持續暴露中間態，後者先構造完整快照再一次性切換入口。對由大量小檔案組成的建置產物，中間態機率隨檔案數近似線性放大。rsync 雖亦逐檔傳輸，但當目標為 新的版本目錄 且最後才切換軟連結時，對外可見路徑在校驗通過前仍指向舊快照，風險收斂為一次 metadata 操作。
決策矩陣：in-place SFTP 上傳 vs rsync 暫存目錄 + current 軟連結
| 維度 | in-place 覆蓋 | rsync 至 releases + 軟連結 |
|---|---|---|
| 線上中間態 | 高 | 低（僅切換瞬間） |
| 典型回滾時間 | 數分鐘（重傳或解壓） | 保留上一版時常小於 5 秒 |
| CI/CD 整合 | 易遺漏順序 | 易標準化：同步→校驗→切鏈 |
| 權限與稽核 | 易共用帳號 | 可按 release 批次標籤 |
實操：releases、rsync 與 ln -sfn（五步）
TS=$(date +%Y%m%d%H%M)
mkdir -p /srv/app/releases/$TS
rsync -av --delete-after --exclude '.git' ./dist/ deploy@remote-mac:/srv/app/releases/$TS/
ssh deploy@remote-mac "test -f /srv/app/releases/$TS/index.html && shasum -a 256 /srv/app/releases/$TS/index.html"
ssh deploy@remote-mac "ln -sfn /srv/app/releases/$TS /srv/app/current && readlink /srv/app/current"
可引用數據：發佈閘門與稽核欄位
建議磁碟預留至少單次發佈包體大小的 2.5 倍；CI 逾時設為平日同步耗時的 3 倍；稽核至少記錄操作主體、UTC 時間、release 目錄名與軟連結切換前後的 readlink，保留 90 天。寫入帳號僅對 releases/* 可寫，Web 行程對 current 唯讀。
回滾清單、FAQ 與為何考慮 SFTPMAC 遠端 Mac
- 確認舊版目錄完整；記錄 readlink。
ln -sfn /srv/app/releases/PREV_TS /srv/app/current，必要時刷新 CDN。- 抽樣比對雜湊並監控錯誤率。
上述流程在自建 Mac mini、雲主機或 租賃遠端 Mac 皆可複現；差異在磁碟監控、網路出口穩定度與 7×24 在線成本。當發佈頻次上升，將 目錄隔離、SFTP 准入與在線率 交給託管方，能把心力留在產品與流水線。
SFTPMAC 提供面向開發者與 CI 的遠端 Mac 與 SFTP，您可在受控目錄內繼續使用 rsync 與軟連結模型，由服務方保障節點可達與權限基線。若您正從 in-place 上傳遷移到原子發佈，建議先在預發環境跑通「同步→校驗→切鏈」再切正式環境。
為何 in-place SFTP 風險高？
上傳中讀者可能讀到半套檔案；大目錄易新舊混用；失敗重試難界定一致快照。
若希望減少自管遠端 Mac 的磁碟、權限與在線率問題，可了解 SFTPMAC 套餐與節點選型。