2026 年远程 Mac CI 缩小 rsync 传输面：`--files-from`、分层 manifest 与 sparse-checkout 决策指南
远程 Mac CI 最常见的性能悬崖不是磁盘，而是把整棵工作区当作 rsync 目标：海量小文件让跨国链路长时间停在扫描，也把日志与缓存误推到制品目录。2026 更务实的路径是「清单 + 仅传必要路径 + staging 原子切换」，并用 sparse-checkout 收敛仓库工作面。
目录 (TOC)
1. 远程 Mac CI 为什么会被「盲同步」拖垮？三类典型痛点
第一类痛点是枚举成本：rsync 要先确定对比路径；DerivedData、SwiftPM 缓存与日志让跨国 RTT 下的列目录变成分钟级浪费，而真正需要的可能只是数百 MB 的 .ipa/.app/dSYM。
第二类痛点是误传风险：环境文件、临时密钥或未脱敏日志可能被推到多人 SFTP 目录，违背最小权限与审计。
第三类痛点是一致性难证明：缺少 manifest 只能用「时间戳最新」判断产物；清单把路径、哈希与字节数前置为契约。
- 扫描爆炸：无关小文件数量上升时，CPU 与元数据往返同步放大。
- 带宽浪费：重复推送未变更的资源包与缓存切片。
- 协作摩擦：多人并行 Job 争用同一上传目录，缺少 staging 分层更易互相踩踏。
2. 决策矩阵：整目录 archive、清单同步与分层 tarball 的边界
下列矩阵用于判定何时从整目录 `-a` 迁移到 manifest + `--files-from`，以及何时仍应打包 tarball（远程 Mac 对外 SFTP/rsync，下游自动拉取）。
| 维度 | 整目录 rsync（archive） | `--files-from` + manifest | 分层 tarball + 校验 |
|---|---|---|---|
| 路径可控性 | 低，易混入缓存 | 高，清单即契约 | 高，但解压步骤多 |
| 扫描成本 | 随目录规模上升 | 近似线性随清单长度 | 上传单文件，扫描低 |
| 增量粒度 | 文件级 delta | 文件级 delta（受限集合） | archive 级，适合大体积资源 |
| 审计友好度 | 需额外工具比对 | manifest 即证据链 | 哈希清单可外挂 |
| 典型适用 | 小到中型静态站点 | iOS/macOS 构建产物树 | 巨型素材 bundle |
3. 可复现 How-to：manifest、`--files-from`、dry-run 与 staging 红线
流水线建议七步：分层输出 → manifest → files-from → dry-run → staging → 哈希验收 → 切换 current。核心骨架如下。
# 1) 假设 manifest.txt 每行是相对 BUILD_ROOT 的路径
rsync -avh --files-from=manifest.txt \
--checksum --partial \
-e "ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=4" \
./build/ ci-upload@remote-mac:/srv/releases/staging/build-123/- 固化分层目录：按芯片架构、渠道包、符号表、dSYM 分层；禁止把 DerivedData 直接挂在同步根下。
- 生成 manifest：输出 CSV（path, sha256, bytes, mtime）；CI 失败时打印Top-N最大文件帮助定位异常膨胀。
- 过滤敏感路径：显式排除含有密钥模板、`.env`、本地证书与调试日志的 glob。
- dry-run：上线新流水线的第一周固定开启 `-n`，并把差异列表存档供安全复核。
- staging-only 删除：`--delete` 仅作用于 `/releases/staging/...`，永不指向共享缓存卷。
- 心跳与限速：跨国链路加 `ServerAliveInterval`；多 Job 并行时用 `--bwlimit` 做邻居友好调度。
- 切换 current：哈希对齐后原子更新软链接或发布清单，触发下游拉取。
4. Git sparse-checkout 与最小工作区：避免无关模块污染扫描
稀疏检出把编译子树收敛到有限路径，减少无关中间文件；把 CI profile 写入仓库文档，并在 checkout 后输出 `git sparse-checkout list` 作为可观测信号，避免误剪 Xcode workspace 引用。
sparse-checkout 不替代 manifest，但能缩短清单、降低误把缓存当产物的人为失误。
5. 可引用数据：传输体积、扫描耗时与失败回滚的量化口径
跟踪清单条目数、manifest 总字节与rsync 实际发送字节；当枚举从上万路径收敛到数百以内时，跨国扫描阶段通常可从数分钟降到数十秒级（仍取决于 RTT 与磁盘）。回滚以「上一版 manifest 可还原」为准。
并行 Job 多用独立 staging 前缀并写入 `job_id`；共享依赖缓存只读挂载，防止 `--delete` 触及。
6. FAQ：清单模式下的 `--delete`、权限与共享缓存
问：会漏传隐藏文件吗？答：在生成器里显式包含 `.xcconfig` 等并用 dry-run 计数校验。
问：能与 SFTP GUI 并行吗？答：需单一权威目录或拆分人工上传子树，避免覆盖。
问：xattr？答：确认远端支持后用 `-E`，并 spot-check 签名旁数据。
7. 总结：何时值得把节点托管给专业远程 Mac 平台
清单 + sparse-checkout 让链路时间花在「有价值的字节」上，但仍需要稳定上行、可预期 IO 与长时间在线。
自建节点常遇带宽抖动、磁盘争用与多人同账号上传，manifest 也会被迫频繁人工救火。目录隔离、可审计路径与专线级带宽的托管远程 Mac，更易把流水线沉淀成默认安全的基线。
希望跳过线路试错，可看 SFTPMAC 远程 Mac 租赁，把上传当成可复制模块。