2026年独占远程 Mac CI：Swift Testing（宏）与 XCTest 混跑怎么裁？——编译耗时、并行度、Simulator 配额与 SSH 无头 flaky 决策矩阵 + FAQ
在独占一台远程 Mac 跑 CI 时，Swift Testing（依赖编译期宏展开的新测试框架）与存量 XCTest 往往长期并存。「裁」的不是二选一宣言，而是编译分区、并行上限、Simulator 启动配额、以及 SSH 无头环境下的复现纪律。下面把可执行判断收成矩阵与 FAQ；依赖解析与锁文件策略可对照
SwiftPM Package.resolved 是否提交与 CI 可复现；
Runner 池与分钟成本视角可对照
GitHub Actions 自托管 Runner 与独占 Mac 资源池 TCO。
1. 混跑时「编译耗时」最先爆炸：宏与 XCTest 的分区
Swift Testing 的断言与套件组织大量依赖宏（例如 #expect、@Suite 等写法，视工具链版本而定）。宏展开会增加前端工作量与增量编译的重编面；与 XCTest 混在同一 test target 里时，一次小改动也可能触发「 XCTest 桥接 + Swift Testing 生成代码」的双重编译路径。
- 推荐默认：为 Swift Testing 单独划分
*.xctest／SwiftPM test target，与 legacy XCTest target 物理隔离；主工程 Scheme 用 Test Plan 控制「PR 门禁跑哪几组」。 - CI 裁剪：在「仅改 UI / 仅改 ObjC 桥」类 PR 上跳过 Swift Testing target，需要明确的文件路径或
CODEOWNERS规则，避免误跳过。 - 工具链钉死：
xcodebuild -version与 Swift 语言模式写入 Runbook；宏行为随编译器升级变化，比 XCTest 更敏感。
2. 编译耗时裁切：决策矩阵
| 症状 | 优先动作 | 代价 |
|---|---|---|
| Clean build 测试阶段占比过高 | 拆分 Swift Testing target；打开模块稳定化与 DerivedData 缓存键规范化 |
Scheme／Test Plan 维护成本上升 |
| 增量编译仍慢、宏相关文件频繁重编 | 减少「巨型共享 fixture」被宏文件 transitively import；审查 @testable import 范围 |
需要代码层解耦 |
| 仅夜间全量、PR 要极快 | PR 跑 Swift Testing 冒烟子集 + main 合并前跑全 XCTest／全量 | 分层门禁要防「子集绿、全量红」 |
3. 并行度：混跑不是「线程加倍」
xcodebuild test 的并行测试会放大Simulator 进程数、磁盘 IO 与编译子进程。Swift Testing 与 XCTest 同一次 invocation 内并行，往往比「两次顺序单框架」更争用内存——因为链接产物与运行时元数据都在同一用户空间。
- 基线做法：先以
-parallel-testing-enabled NO或限制-maximum-parallel-testing-workers建立稳定基线，再阶梯加压记录失败率。 - 分拆 Job：Swift Testing target 与 XCTest target 分到两个 CI Job（仍是一台独占机时串行），换取更清晰的
xcresult归因。 - 与 UI 测试隔离：UI 测试与单元／Swift Testing 不要共享高峰并行度；否则 Simulator 启动风暴会掩盖真实的编译问题。
4. Simulator 配额：独占机也有硬上限
独占消除租户间争抢，不消除 CoreSimulatorService 与内存页压力。经验上，并发 boot 的模拟器数量与可用 RAM、SSD 余量、以及是否同时跑 watch/tv 目的地强相关。
| 机型内存档 | 建议并发 Simulator 上限（起点） | 备注 |
|---|---|---|
| 16GB | 1–2 个重度 UI／混合测试；纯逻辑可略高但仍需压测 | Swift Testing + XCTest 同跑时偏保守 |
| 24–32GB | 2–4 视 destination 与截图／录屏开关 | 监控 memory_pressure 与 SSD 延迟 |
| 64GB+ | 可更高，但仍受 Xcode／系统 bug 与 IO 尾延迟约束 | 「高内存 ≠ 无限并行」 |
Runbook 应写明：每次 Job 前销毁／复用 booted 设备策略、是否 xcrun simctl shutdown all、以及是否与钥匙串／登录会话相关（见下一节）。
5. SSH 无头 flaky：裁「环境」而不是裁用例
通过 SSH 触发 xcodebuild 时，常见 flaky 来自图形会话、钥匙串解锁、Simulator 首次启动竞态、以及无显示器时的 GPU 路径差异。与 Swift Testing／XCTest 本身无直接因果，但会在「并行提高」后集中暴露。
- 会话类型：区分
launchdAgent、ssh 非交互 shell、与屏幕登录用户；同一测试在三种环境下权限边界不同。 - 钥匙串：签名／嵌入式 provisioning 若依赖交互式解锁，CI 会间歇失败；用专用 CI 用户 + 预置描述文件／非交互凭据注入，并在 Runbook 记录轮换。
- 复现门槛：对「仅 CI 红」用同一 SSH 命令重放 + 固定
SIMCTL_CHILD／随机种子；连续 N 次一致再改测试或产品代码。
6. 总览决策矩阵（怎么裁）
| 你的约束 | 倾向裁法 |
|---|---|
| PR 延迟敏感、宏编译重 | Swift Testing 独立 target + PR 子集；全量夜间 |
| 稳定性优先、偶发超时 | 降低并行 worker；拆分 Job；Simulator 串行 boot |
| SSH 无头、无登录 GUI | 先修会话／钥匙串／启动竞态；再谈加并行 |
| 报告要单一真相源 | 每 Job 单一 xcresult 路径；避免多阶段互相覆盖 |
7. FAQ
Q1：能不能把所有测试都迁到 Swift Testing 再关掉 XCTest？
可以作方向，但 CI 裁切应分阶段：先并行共存、按模块迁移、用 Test Plan 控制门禁集合；一次性切换会让编译图与 flaky 归因同时失控。
Q2：Swift Testing 宏导致编译慢，能否只靠加大 -j 或更多 Runner？
横向扩容掩盖不了单 target 宏扇出；若瓶颈在 Swift 前端，增加并行 Job 可能放大 IO 与 Simulator 争用。优先 target 拆分与缓存键。
Q3：独占 Mac 上仍然 flaky，是不是测试写坏了？
不一定。先对照本节 SSH／钥匙串／Simulator 配额清单做二分：同一提交在本地 GUI 用户绿、仅 SSH 红，优先判定为环境类 flaky。
在 Mac mini 上固化这套裁切策略
Swift Testing 与 XCTest 混跑对 CI 的真实要求是可预测的编译图、稳定的用户会话与足够的内存带宽。Apple Silicon Mac mini 在长时间 xcodebuild 与多 Simulator 混合负载下仍具较好能效比，适合作为独占自托管节点；macOS 上 SSH、脚本与钥匙串自动化路径成熟，比异构云 Mac「黑盒」更易写进 Runbook。安全面向上，Gatekeeper、SIP 与 FileVault 便于为 CI 专用账户做最小暴露面；总拥有成本上，小体积、低待机功耗与静音运行对 7×24 流水线更友好。
若你希望把上述矩阵落到一台可长期独占的机器上，Mac mini M4 仍是 2026 年高性价比的起点——从首页了解套餐，把并行度基线与 Test Plan 一起固化即可。