三类痛点：為什麼「会传文件」不等于「能長期托管交付」
痛点 1：把镜像当成發佈。rclone 擅长在远端维护與本地一致的目錄树，但若直接同步到面向下载用户的生产可見目錄，一次誤刪源端或错误过滤规则就可能級聯删除对端文件。对遠程 Mac上的 iOS/macOS 产物，更安全的模式是先落到暫存区，再执行軟連結切換，这與站内《原子發佈》的模型一致。
痛点 2：SFTP 賬號权限與工具能力错配。仅 SFTP、chroot 后的賬號往往不能执行 shell，rclone 的 SFTP remote 仍可工作，但依赖 sftp 子系统特性；若誤用需要远端执行命令的協議假設，会在日誌里表现为模糊的超時。必须先按《Chroot 多租戶》核对屬主與 jail 根目錄。
痛点 3：CI 机密钻进配置文件。在 runner 上执行 rclone config 交互生成 ~/.config/rclone/rclone.conf 时，若把含密碼字段的文件缓存到次日 job，等同拉长憑據壽命。应與《CI/CD 憑據矩陣》一致：短期密鑰、环境隔離、日誌脫敏。
补充：镜像與上傳分賬號或前缀；对齐《并发 SFTP》與 rclone 并发。多源混用须可審計；镜像勿指 current；机密 conf 短期注入；跳板写入 remote。
能力对照：rclone、rsync over SSH 與交互式 SFTP 各解决哪类问题
rsync over SSH适合「已知两端路径、以增量字节为主」的構建产物推送；配合 --partial、校验與發佈闸门，在 CI 中极为常见。交互式 SFTP适合人工排障與小批量拖拽。rclone在「多后端统一语法、需要可恢复的任务佇列式同步、跨云对象存储與 SFTP 混合」时更顺手；对单一遠程 Mac 入口，它并不是 rsync 的替代品，而是互補。
rclone 的 SFTP remote 使用 SSH 子系统，仍受服务器认证方式约束：公钥、证书、跳板與 known_hosts 策略要與现有運維模型对齐。其 checksum、compare 相关 flag 與站内《传输完整性》中的闸门哲学一致：退出码为零不等于业务上允许發佈。
若你需要唯讀镜像，在 Mac 侧用 rclone 定时同步，并把目标目錄與 CI 上傳目錄从权限上隔離，防止镜像與發佈互相覆盖。
决策矩陣：按场景选择 rclone / rsync / 纯 SFTP
評審结论写入工單：同步方向、賬號、目錄前缀、是否允许删除对端、是否與原子發佈目錄衔接。
| 场景 | 首选工具 | 关键风险 | 與站内文档衔接 |
|---|---|---|---|
| CI 推送構建产物到固定 releases 暫存区 | rsync over SSH | in-place 覆盖、半套文件对外可見 | 原子發佈、完整性校验 |
| 对象存储 → 遠程 Mac 素材镜像（唯讀使用） | rclone（S3/GCS ↔ SFTP） | 誤配删除、过滤规则漂移 | Chroot 與独立唯讀賬號 |
| 人工排障、小文件抽檢 | SFTP 用戶端 | 无自动化、易跳过校验 | 工具选型长文 |
| 跨多云聚合后落到单一 Mac 入口 | rclone + 统一 remote 命名 | 憑據分散、日誌难关联 | CI 憑據矩陣、SSH CA |
矩陣定义多工具并存时的职责边界，靠賬號、目錄與 sshd Match 固化。
实操：rclone 对接遠程 Mac SFTP 的最小可复现步骤（七步）
在测试目錄验证；生产 remote 密碼/密鑰使用 CI 注入或短期文件；勿将含机密的 conf 提交到 Git。
# 步骤 1：确认目标賬號为仅 SFTP + 目錄前缀，與 Chroot 指南一致
# 步骤 2：在 CI 中生成临时 ssh 私钥或挂载短期证书，仅当前 job 可見
# 步骤 3：非交互创建 remote（示例字段名按 rclone 文档调整）
rclone config create mac_sftp sftp \
host sftp.example.com \
user mirror_ro \
key_file "$RUNNER_TEMP/ci_ed25519" \
shell_type none
# 步骤 4：先用列表與单文件 copy 验证路径與权限
rclone lsd mac_sftp:uploads
rclone copy ./marker.txt mac_sftp:uploads/ci_probe/ -v
# 步骤 5：镜像同步时显式关闭危险默认（按需求选择）
# rclone sync 会删除对端多余文件，生产慎用；可用 copy + 生命周期策略
rclone copy ./assets mac_sftp:assets_mirror/ --transfers 4 --checkers 8 \
--sftp-connections 2 -v
# 步骤 6：與原子發佈衔接：只同步到 staging/releases/<build_id>/，再由站内脚本切換 current
# 步骤 7：记录退出码與摘要日誌；與 SHA256 清单闸门联动（见《传输完整性》）
若必须 sync，先在 dry-run 模式核对删除集；对生产可读目錄优先只 copy并由另一侧流程做淘汰。
可引用数据與基线参数
建议基线：（1）CI 侧 rclone --transfers 初始取 4，在观测 sshd CPU 與 RTT 后再上调。（2）--checkers 與 --sftp-connections 乘积不宜超过你为该賬號规划的并发会话预算。（3）跨洲链路 ServerAliveInterval=60 與 rsync/SSH 用戶端保持一致。（4）發佈闸门仍建议独立 SHA256 清单，不把「工具校验成功」等同于「允许切換 current」。
人力吃紧时，维护多入口與多租戶策略成本高；托管遠程 Mac可收敛入口與隔離模型。握手 P95 超 800ms 时先查跳板與会话表；日誌关联 run_id 與賬號。
FAQ、内链與为何考虑托管遠程 Mac
rclone 能替代 rsync 做 CI 發佈吗？
可以，须自建發佈语义與《原子發佈》模型；多数团队 rsync 推产物，rclone 做多后端镜像。
唯讀镜像賬號还能被 CI 誤用吗？
能，若同一密鑰被复制到另一个 workflow。应对是拆分密鑰、拆分 remote 名，并在 sshd 层用 Match 强制目錄前缀。
和 OIDC 短期憑據如何衔接？
在 job 开始写入短期密鑰文件，再执行 rclone；结束即删；與《CI/CD 憑據矩陣》一致，不把长壽命 material 落盘在自托管 runner 上。
总结：rclone 與 rsync/SFTP 互補；用賬號與目錄边界拆分镜像、上傳與發佈，并叠加完整性與并发治理。
局限：自建多入口與多租戶耗工程时间；SFTPMAC 托管遠程 Mac可打包隔離與入口，让你专注产物與發佈节奏。
若要在隔離遠程 Mac 上落地 rclone 镜像與 rsync 發佈并降低维护成本，可了解 SFTPMAC 套餐與区域。