远程 Mac CI 流水线上 rsync 压缩与预压缩制品传输路径对比示意

2026 年远程 Mac CI 与 SFTP/rsync 链路上要不要开压缩：`rsync -z`、预压缩制品与 openrsync/Brew rsync 的吞吐决策矩阵

很多团队在第一次把制品同步到租赁或自建的远程 Mac时，会本能地给 rsync 加上 -a 顺手再带一个 -z，仿佛「压缩总更省带宽」。但在 2026 年的真实链路里，制品常常是预压缩包，链路又叠加了 SSH 加密与跨国 RTT；此时 -z 往往把瓶颈从网线挪到 CPU，反而让并行 Job 与交互式 SFTP 一起卡顿。本文给出一套按制品类型分桶的决策矩阵，并说明如何在 macOS 自带的 openrsync 与 Homebrew rsync 3.x 之间做可重复验证。

目录 (TOC)

1. 痛点拆解：二次压缩、加密与队列化三者的叠加

二次压缩：.tar.gz、.zip、.ipa 等高熵制品再经 zlib，CPU 空转、load 飙升而带宽曲线平淡；与《rsync 对比 SFTP 跨国大文件》「省略 -z」一致，但模板仍常写死 -az。

加密叠加：SSH 前压缩会挤占握手与小包调度，体感「列目录变慢」；《bwlimit 专文」讲队列争用，本文聚焦压缩开关。

工具链分裂：openrsync 与 Brew rsync 3.x 默认值不同；Runner 与远程 Mac 二进制不一致时参数可能 silent 分歧，须把版本对齐写入基线。

  1. 指标只看 Mbps：忽略 p95 CPU 与磁盘 await，会误判「网络不忙」。
  2. 把日志当文本传：大体积结构化日志其实可 gzip 后再传，而不是对整棵 build 目录开 -z。
  3. 忽略预发布 tar 策略：上万小文件目录在 RTT 高时应当先 tar cf 再传单文件，详见跨国专文中的「单包化」段落。

2. 决策矩阵：何时 -z、何时预压缩 tar、何时完全关闭

矩阵按「制品熵 × 链路形状」划分；已用《link-dest 快照》时，请单独标注「仅文本变更」子集，避免对大二进制重复压缩。

制品/目录类型 默认 rsync 压缩 更优替代 注意
未压缩文本/JSON/YAML/日志片段 可试 -z 窄上行优先；并行 Job 多时下调 观察 CPU p95
.tar.gz / .zip / .ipa 关 直接传或分块+校验 避免二次压缩
未压缩二进制/框架切片 视内容 样本基准后再定 大块随机数据无益
海量小文件目录 次要 先 tar 再传 + --files-from RTT 主导时压缩救不了 walk

3. How-to：七步验证流水线与命令模板

用 manifest 的 transport_hint 列固化是否 -z，与《files-from 清单》联动。

# 文本诊断包：允许 -z；制品目录：显式关闭
RSYNC_RSH="ssh -o ServerAliveInterval=25"
rsync -av --no-g -e "$RSYNC_RSH" ./artifacts/precompressed/ user@remote:/srv/in/
rsync -avz --no-g -e "$RSYNC_RSH" ./diagnostics/text-only/ user@remote:/srv/logs/
  1. 分桶清单：在 manifest 标注每行路径的 MIME/后缀与是否已压缩。
  2. 双二进制对照：在远程 Mac 执行 rsync --version，记录是 openrsync 还是 brew 3.x。
  3. 三次 dry-run：同一数据集分别用 -z 与 --no-g 观察总发送量与耗时，不要只看第一次。
  4. 小样本实传：复制 200MB 代表性子集到 staging，记录 CPU、load、磁盘 await。
  5. 与 partial 共存：确认 --partial-dir 与临时文件名不与压缩缓存打架。
  6. 加密侧留余量：若已开 VPN，再开 -z 前先看 VPN CPU 占用。
  7. 写回默认模板：把结论固化到 composite action，并在 code review 检查清单里强制。

4. 可引用数据：Apple Silicon 与 30Mbps 上行的交叉区间

用 staging 实测填基线表：例「30Mbps、RTT 180ms」下文本日志开 -z 可缩 wall time；同链路传 2.1GB .tar.gz 开/关 -z 时间差在噪声内而 CPU 多占三成——数字必须来自自家环境。

多租户远程 Mac 上，错误默认 -z 会抬整机 load，影响他人 SFTP，应纳入变更窗口。

5. 组合阅读：bwlimit、SHA256 闸门、files-from 清单

压缩不解决完整性：切换对外目录前串联《SHA256 闸门》与 partial；多 Job 时并联 bwlimit 专文做 CPU 与带宽预算。

6. FAQ：VPN、openrsync、与 SFTP 纯传大文件

问：能不能用 SFTP 代替 rsync 来「绕开压缩困惑」？答：SFTP 仍是逐文件协议，海量小文件时 RTT 成本更高；大单一制品可用 SFTP，但树状同步仍建议 rsync + 清单。

问：Homebrew rsync 是否总是更快？答：不一定；要看 delta 算法、文件集形状与是否启用 ACL/xattr；必须以同一远程路径基准测量。

问：能否 SSH 层开压缩代替 rsync -z？答：会把所有会话绑在同一策略上，更难按目录细粒度控制；通常不如在 rsync 层按 manifest 分桶。

7. 总结与 SFTPMAC 远程 Mac 收束

把 -z 从「肌肉记忆」改成按制品熵与链路形状分桶的策略，可以把远程 Mac CI 的吞吐波动从玄学变成可度量工程；当 openrsync 与 brew rsync、Runner 与远端版本都被写入基线后，排障会少一半「在我机器上能跑」的争议。

但该方法仍依赖你们自建或租用的节点是否提供一致的二进制、足够的 CPU 余量、以及可审计的变更窗口；若团队缺少专职平台工程，manifest 列很快会在紧急发布里被绕过，默认又回到 -az 全家桶。

若你希望获得已对齐的 rsync 变体、制品目录模板、以及与 bwlimit/并发专文一致的默认脚本基线，可以查看 SFTPMAC 远程 Mac 租赁 与帮助中心，把压缩策略、公平队列与目录权限隔离交给托管环境，而不是在每个自建节点上重复试错。