远程 Mac 跑 Xcode：本地构建、远程构建还是共享屏幕？

通过网络共享项目并不会搬走 Xcode，因为应用仍在你自己的 Mac 上运行，并持续向服务器请求项目数据。在远程 Mac 上运行 Xcode 并查看它的屏幕是另一种安排：应用与文件待在一起，链路只承载画面和你的输入。在配置任何东西之前先想清楚要哪一种，能消除之后的大部分困惑。

三种安排覆盖常见情形，区别在于工作区放在哪里、由哪台机器编译。继续之前，把这两点的答案写下来。

先确定运行 Xcode 的机器

第一种安排全部在本地：工作副本、索引和构建都在你的 Mac 上，网络只承载仓库和依赖流量。第二种，项目与 Xcode 一起留在远程 Mac 上，索引和编译在文件旁边进行，链路承载屏幕内容和击键。第三种，编辑在本地完成，经过明确的源码交接后在远程主机上执行构建。下表列出每种安排各自搬运什么。

先读中间一列，因为它决定故障会出现在哪里。源码在远程的工作流会在链路慢时失败，而带远程编译器的工作流会在交接不明确时失败。只有第三种会让你同时为两者负责。

数往返次数，而不是数兆字节

编辑器和索引器会发出大量细小的文件操作，当文件系统在远程时，每一次都变成一个往返。这使挂载的工作区对延迟敏感，而单个大文件复制并不如此，所以给一次文件传输计时，几乎说明不了工作流的实际体感。远程显示正好相反：它搬运连续的数据流，对吞吐量的容忍度高于对延迟的容忍度。用一个数字比较两者，会得出一个自信却错误的答案。

没有哪种安排在本质上最快。正确的选择取决于你实际做的工作，所以下一步是去试那项工作，而不是跑基准测试。

把源码交接明确下来

当两台机器都持有工作副本时，要决定哪一份是权威的，以及远程构建用了哪个修订版。提交比两个工具同时编辑一棵挂载的工作树更清晰，因为提交有身份，而挂载没有。生成产物和索引数据也需要归属，因为它们由源码重建，不应像源码一样来回搬运。没有冲突规则的双向镜像不是工作流，而是一场竞速。

远程构建还 要求远程主机具备正确的工具链 以及私有依赖所需的凭据。能让你连上主机的 VPN 不会把账户访问权借给它，也不会在那里安装 Xcode。

在选定工作流之前先检查路径

在围绕远程主机设计之前先验证它，然后用工作流真正会执行的操作来测量链路。下面的命令检查工具链、当前开发者目录，以及让远程工作区变得难受的文件观察成本。最后一条要在网络路径上运行，而不是在本地运行。

xcode-select -p
xcodebuild -version
ssh mac-builder 'xcodebuild -version'
time git status --porcelain

没有完整 Xcode 安装的主机会从 xcodebuild 返回错误，这是工具链问题，不是网络问题。开发者目录显示构建将使用哪个 Xcode，而只指向命令行工具的路径意味着应用没有安装。在挂载共享上给仓库状态命令计时，会直接暴露往返成本，再与本地运行对比，就得到真正重要的那个数字。如果这个差距已经让人难受，那么挂载工作区的工作流在真实编辑器下只会更糟。

记录你选择了哪种安排、哪台机器拥有源码，以及交接如何运作。这条记录会让下一次入职或换笔记本变成配置任务，而不是一次排查。