为什么 2026 年 macOS Sequoia 要用 openrsync，对远程构建同步有什么影响
Apple 在 macOS Sequoia 中用 openrsync 替代了沿用多年的 rsync，主要原因与 GPLv3 许可策略有关。系统自带的 rsync 2.6.9 年代久远，而新版 rsync 3.x 采用 GPLv3，苹果选择引入 BSD 许可的 openrsync 以规避合规与分发限制。对开发者而言，openrsync 体积更小、性能有优化，但在远程守护模式（rsync daemon）、ACL 及部分权限同步行为上与 rsync 3.x 存在差异，若你的流水线依赖这些特性，就需要提前评估：要么继续使用 Homebrew 安装的 rsync 3.x，要么接受 openrsync 的功能边界并调整脚本。
远程构建同步场景下，影响主要集中在三方面：一是增量校验与 delta 传输的兼容性，二是目标端权限与时间戳的保留程度，三是与现有 CI（如 GitHub Actions、Jenkins）中 rsync 命令的兼容性。多数“只做本地到远程目录同步”的用法，openrsync 可以胜任；一旦涉及 daemon 模式、复杂 ACL 或跨多节点同步，建议仍使用完整版 rsync。
rsync 与 openrsync 功能对比表：权限、ACL、远程守护模式差异
下表从远程构建同步常用能力出发，对比系统 openrsync 与 Homebrew rsync 3.x，便于你按需选型。
| 能力 | 系统 openrsync (Sequoia) | Homebrew rsync 3.x | 对构建同步的影响 |
|---|---|---|---|
| 增量 / delta 传输 | 支持 | 支持 | 两者均能满足增量同步，差异不大 |
| 远程 daemon 模式 | 有限或行为差异 | 完整支持 | 若 CI 通过 rsync:// 拉取产物，建议用 Homebrew rsync |
| ACL / 扩展属性 | 部分支持 | 完整支持 | 需严格保留权限时选 rsync 3.x |
| --fake-super | 计划中 (openrsync 路线图) | 支持 | 非 root 保留 full permissions 时依赖此项 |
| 维护与升级 | 随系统更新 | brew upgrade rsync | 长期可控性 Homebrew 更灵活 |
结论：若仅做“本机或 CI 到远程 Mac 目录”的增量推送、且不依赖 daemon 与复杂 ACL，可先尝试系统 openrsync；否则建议在构建节点上统一安装 brew install rsync，并显式使用 /opt/homebrew/opt/rsync/bin/rsync 或 PATH 优先，避免与系统自带的 openrsync 混用。
远程 Mac 上构建产物同步的推荐方案（Homebrew rsync / Docker rsync / SFTP）
三种常见做法的适用场景与注意点如下。
- Homebrew rsync： 在远程 Mac 上执行
brew install rsync，CI 或本机通过 SSH 调用该 rsync。适合已标准化 SSH 访问、且希望保留完整 rsync 能力的团队。注意确保 PATH 中优先使用 Homebrew 版本，避免与系统 openrsync 混用。 - Docker rsync： 在远程 Mac 上以容器运行 rsync 3.x 服务，保证版本一致、不受系统变更影响。适合多节点、多系统混杂的环境，但需要维护镜像与网络映射，复杂度较高。
- SFTP 网关 + 目录隔离： 不依赖 rsync daemon，通过 SFTP 上传/下载构建产物，配合严格目录权限与审计。适合更看重权限边界、多角色交付与合规审计的团队；若仍需增量同步，可在 SFTP 准入之下再在“允许的目录”内使用 rsync over SSH。
实际落地时，很多团队采用“SFTP 做准入与权限，rsync 做大批量增量同步”的混合方式：SFTP 保证只有授权账号能访问指定目录，rsync 在该目录内负责高效增量传输，兼顾安全与效率。
ENOSPC、ECONNREFUSED 等常见同步失败场景排查与解决
下面给出 5 步排查流程与对应处理思路。
# 1. 确认本机使用的 rsync 路径（避免与 openrsync 混用）
which rsync
/opt/homebrew/bin/rsync --version
# 2. 测试 SSH 与目标磁盘空间（避免 ENOSPC）
ssh user@remote-mac "df -h /path/to/dest"
ssh user@remote-mac "df -i /path/to/dest" # inode 是否耗尽
# 3. 检查目标端是否在监听（避免 ECONNREFUSED）
# 若用 rsync daemon：netstat -an | grep 873
# 若用 rsync over SSH：确保 sshd 正常、防火墙放行 22
# 4. 干跑一次，看实际传输列表
rsync -avzn --delete ./build/ user@remote-mac:/path/to/dest/
# 5. 正式执行并保留日志
rsync -avz --delete ./build/ user@remote-mac:/path/to/dest/ 2>&1 | tee rsync.log
ENOSPC： 表示目标磁盘或 inode 已满。清理目标目录、归档旧产物或扩容；必要时在 CI 中增加“同步前检查磁盘空间”的步骤。
ECONNREFUSED： 表示对端未监听或防火墙阻断。若走 SSH，检查 sshd 与 22 端口；若走 rsync daemon，检查 873 端口与 rsyncd.conf。
Permission denied / 权限相关： 确认目标目录属主与 SSH 用户一致，以及是否依赖 ACL/--fake-super，若需完整权限保留，优先使用 Homebrew rsync 并查阅其文档。
决策清单：按团队规模与系统版本选 rsync/openrsync 还是 SFTP 托管
- 仅本机或单节点、Sequoia 自带 openrsync 即可满足： 直接使用系统 rsync，脚本中避免依赖 daemon 与复杂 ACL。
- 多节点 CI、需 daemon 或严格权限： 统一在各节点安装 Homebrew rsync，并固定使用其路径。
- 更看重权限边界、审计与多角色交付： 引入 SFTP 网关 + 目录隔离，必要时在允许的目录内再使用 rsync over SSH。
- 希望减少对单机系统与 rsync 版本的依赖： 考虑将“构建产物托管”整体迁到提供 SFTP 的远程 Mac 托管服务，由服务方保证可用性与权限策略，本地或 CI 只做上传/下载与校验。
rsync 与 openrsync 在多数“目录级增量同步”场景下都能工作，真正决定体验的是：版本统一、路径一致、以及故障时的快速排查。当团队规模扩大、合规与审计要求提高时，仅靠 rsync 往往不够，需要清晰的准入层（如 SFTP）和稳定的远程运行环境。
macOS Sequoia 下为什么系统自带的 rsync 换成了 openrsync？
因 GPLv3 许可与苹果策略冲突，Apple 在 macOS Sequoia 中将传统 rsync 替换为 BSD 许可的 openrsync。openrsync 体积更小、性能有提升，但在远程守护模式、ACL 及部分权限同步上与 rsync 3.x 存在差异，远程构建同步场景需注意兼容性。
远程 Mac 上构建产物同步用 rsync 还是 SFTP 更好？
若团队已统一使用 rsync 且需增量与校验，可继续用 Homebrew 安装的 rsync 3.x；若更看重权限边界、审计与多角色交付，SFTP 网关配合目录隔离往往更易管控。两者可并存：SFTP 做准入与权限，rsync 做大批量增量同步。
同步报 ENOSPC 或 ECONNREFUSED 怎么排查？
ENOSPC 表示目标磁盘或 inode 已满，需清理目标或扩容；ECONNREFUSED 表示对端服务未监听或防火墙阻断，需检查 sshd、rsync daemon 或 SFTP 端口是否开放，以及本机与远程 Mac 的网络与防火墙规则。
在自管 Mac 或 CI 节点上维护 rsync/openrsync 版本与排查网络与磁盘问题，会占用不少精力。若你更希望把时间用在业务交付上，可考虑将构建产物同步与权限管控交给专业远程 Mac 托管：SFTPMAC 提供稳定 SFTP 与目录隔离，兼容 rsync over SSH 的增量同步方式，由我们保障节点可用性与权限策略，你只需专注构建与发布。