首屏摘要：三类「假慢」与你要先量的数
跨洲推 iOS 归档或素材到远程 Mac时常见「千兆出口却只有个位数 MB/s」：单连接受 RTT 与窗口限制；SSH/SFTP占 CPU；rsync 扫描可能触发中间盒空闲掐断。
本文给Runbook 判别顺序：单流 SFTP 与 iperf3 对齐期望，再选并行、rsync 策略或路径优化。吞吐优化不牺牲发布语义：字节进releases 暂存，校验后切current（《原子发布》）；SHA256 闸门见《传输完整性》。
交互式拖拽与 CI 无人值守要共享会话预算：MaxSessions 与客户端并行度须对齐，见《并发 SFTP》；多后端镜像与 rclone 边界见《rclone 决策矩阵》。
痛点拆解：为什么「单流 SFTP」和「rsync 首阶段」最容易背锅
痛点 1：把「标称带宽」当成「单连接应得带宽」。在跨太平洋或跨洲链路上，RTT 常常落在 150ms 到 250ms 区间，甚至更高。此时即便物理层能跑数百 Mbps，单条 TCP 连接也可能因为拥塞控制与窗口演化而在长时间尺度上呈现「稳定的中等吞吐」。这不是供应商「缩水」，而是时延带宽积的基本算术。工程上要么接受多路并行（注意与服务器会话上限对齐），要么在可控范围内优化路径（更近区域、更干净跳板、减少层层 NAT）。
痛点 2：rsync 扫描阶段掉线。极大单文件或海量小文件会先耗在元数据/校验；中间盒可能掐「长时间少 payload」的 SSH。拆目录、评估 whole-file、调保活，并把阶段耗时打进 CI 日志。
痛点 3：压缩/加密。已压缩产物再开压缩常被 CPU 绑死；文本日志类可 A/B。按内容熵固化团队配方。
痛点 4：破坏发布语义。禁止 in-place 覆盖对外目录；并行只打不同 build_id 前缀。短期密钥生命周期与并行 job 对齐（《CI/CD 凭据》）。
决策矩阵：何时加并行、何时改 rsync 策略、何时回到架构
评审时把结论记在工单：单流基线 Mbps、RTT、计划并行度、账号会话预算、目标目录是否为 releases 暂存区、是否与 SHA256 清单闸门绑定。
| 观测现象 | 优先假设 | 推荐动作 | 与站内文档衔接 |
|---|---|---|---|
| 单流 SFTP 与 iperf3 单流 TCP 接近 | 窗口/RTT 限制 | 多路并行或更近区域；检查 CPU 是否打满 | 并发 SFTP、rclone 多连接 |
| 仅 rsync 在首阶段掉线 | 空闲会话被掐 | 调保活；拆目录；评估 whole-file；降校验强度（在风险可控前提下） | 传输完整性、原子发布 |
| 局域网极快、跨 WAN 极慢 | 路径与队列 | 检查跳板、运营商 QoS、是否误走代理 | ProxyJump 单入口文 |
| 并行一加就断 | sshd 会话或速率限制 | 下调并行度；拆分账号；排队 | 并发 SFTP |
| 传完但业务不敢发版 | 完整性未闸门 | 独立校验文件；禁止以退出码替代位级一致 | 传输完整性 |
矩阵核心：快与对分门禁；目录与账号边界先画清。
实操步骤：从基线测量到与发布闸门衔接（How-to）
在测试前缀目录演练；生产写入仅指向 releases/<build_id>/；不要把探测脚本指向 current。
# 步骤 1：记录 RTT 与单流基线（示例：替换为你的主机）
ping -c 20 your-remote-mac.example
# 步骤 2：OpenSSH 客户端保活（~/.ssh/config 片段）
Host remote-mac-prod
HostName your-remote-mac.example
User ci_upload
ServerAliveInterval 60
ServerAliveCountMax 3
# 步骤 3：sshd 侧（需权限）与组织策略对齐示例
# ClientAliveInterval 60
# ClientAliveCountMax 3
# 步骤 4：rsync 长传示例（按内容调整校验策略）
rsync -av --partial --inplace ./build/ remote-mac-prod:uploads/staging/build-123/
# 步骤 5：若单流明显低于 iperf3 单流，尝试拆分大文件为多个并行任务（不同目标前缀）
# 步骤 6：校验通过后再执行原子切换（见《原子发布》脚本与 runbook）
# 步骤 7：日志字段：握手耗时、首字节、平均吞吐、重试、退出码 —— 写入 CI 摘要
上述命令是教学骨架，生产环境必须把密钥来源、sudo 边界与日志脱敏写成清单，并与《CI/CD 凭据》一致。
可引用数据与参数基线（便于写进评审表）
经验抓手（非 SLA）：RTT >150ms 且单流长期低于标称 30% 时先查窗口/并行而非磁盘；并行从 2~4 档试起并记录 sshd CPU；ServerAliveInterval=60 常作长传起点；已压缩产物关压缩层常见 1.3~2.1× 表观提升；发布仍靠独立 SHA256 清单，勿以工具校验替代业务闸门。
基线写入 Runbook 可减少「只换客户端」的无效尝试；多入口维护成本高时，托管远程 Mac收敛会话与隔离更省总成本。rclone 镜像须与发布目录分账号，见《rclone 决策矩阵》。
FAQ、站内互链与为何考虑托管远程 Mac
单流慢是否说明一定要换 UDP 类方案？
不一定。多数构建产物链路仍终止在 SSH/SFTP 生态内；UDP 类加速往往引入新的合规与防火墙问题。优先把单流基线、并行与会话预算算清楚，再评估是否值得引入新协议面。
并行上传会打乱文件顺序吗？
字节层面各任务独立；业务层面只要你坚持「只向 build_id 暂存区写入，校验后切换」，就不会出现用户读到半套目录的问题。避免多任务写同一前缀。
Mac 客户端需要特别调 sysctl 吗？
极端案例可调 TCP delayed ack，须走变更流程；优先并行与工具策略。
总结：远程 Mac 大文件上传的「跑不满」多数是单流语义、RTT 与工具阶段成本的综合结果；用基线测量与决策矩阵拆分问题，再用并行与保活落地，同时坚持暂存—校验—切换的发布语义。
局限：自建多入口与多租户调优会持续消耗高级工程师时间；SFTPMAC 提供的托管远程 Mac把隔离、入口与会话策略打包成可消费的服务，让你把精力放在产物质量与发布节奏，而不是深夜排查「为什么又卡在 rsync 第一阶段」。
若希望用统一远程 Mac 入口承载 CI 上传、团队交付与稳定会话策略，可了解 SFTPMAC 套餐与区域节点说明。