2026 Swift Strict Concurrency 迁移：在 Mac 云 CI 上怎么做对门禁——Sendable、CI-only flaky 与五步 Runbook
如果你是移动团队技术负责人，2026 年很可能正在把工程推进到 Swift 6／Strict Concurrency 完整模式；却频频遇到仅在 CI 上爆红、本地却很难复现这类「幽灵告警」。本文为读者拆解三大根因、给出门禁决策矩阵与五步可抄 Runbook，并串联站内 三种算力来源对照 与 Simulator 并行 PR 流水线 两篇长文的可读顺序。
本文要点
1. 痛点拆解：CI-only 告警为什么偏偏找上你
在进入 Swift Strict Concurrency（严格并发检查）深水区之后，很多问题不再「一眼能修」，而是表现为：同事笔记本上静默通过，流水线却稳定失败。这类现象的根往往不在业务逻辑，而在环境与任务形态差异。
- 工具链与时间片差异：CI Job 通常为 headless、`xcodebuild` 在无 UI Session 的条件下执行分析与索引；Swift 前端对并行调度极为敏感——当机器的节能核／性能核与本地开发机比例不同，
@MainActorisolation 推导会出现「只差一条警告就失败」的差异。 - 缓存热度的冰火两重天：DerivedData／模块缓存若在本地常驻温热，Swift 对部分跨模块
Sendable约束会走快速路径；而 CI「冷起跑」或未命中缓存时，会触发更激进的诊断路径，从而在门禁门槛上出现「本地不报、远端报」。这不是编译器玄学，是可度量的输入差异。 - 任务分叉：Smoke / Simulator / Archive 混在同一个标签里：当你在 PR Checks 上用轻量 Smoke，却把 Archive 延后到夜间任务，两者对并发模型的验证深度不同；若未显式分叉，就会把「归档才暴露的问题」误判为 flaky。更多矩阵拆分思路请对照 Simulator 并行与 destination 文中的表格。
2. 决策矩阵：哪个模块先门禁、何时允许暂缓
Strict Concurrency 迁移不是「一口开关打开」；工程上更健康的姿势是按模块划片 + 可审计 PR。下表把常见策略压缩成可贴进评审模板的语言（你可以直接复制列头到工单系统）。若团队还在评估「算力从何而来」，可先读另一篇站内决策长文：GitHub Runner、Xcode Cloud 与专用 Mac 云三者对照。
| 策略维度 | 先门禁的业务信号 | 可先观察窗的原因 | 门禁外的配套动作 |
|---|---|---|---|
| 跨团队协作的数据模型 | 多处 UI／网络层共享可变状态 | 纯内部工具、低风险流量 | 为该模块拆分单独 scheme 与-warnings-as-errors 开关 |
| Actor 边界清晰度 | 已经出现野指针式「偶发卡住」日志 | 仅占少量代码路径的边缘特性 | 为该路径补最小可复现实验与集成测试优先级 |
| 依赖库升级节奏 | 上游已标明 Swift 6 兼容 | 第三方尚未完成 Sendable 标注 | 用 Package 覆盖或二进制隔离层挡在边界外 |
| 运行时成本 | 归档／Test 任务耗时应进入预算表 | 仅开发期一次性脚本 | 在 CI 上对「并发检查等级」分两档：PR 档位与 nightly 档位 |
矩阵的目的：把「感受」转成可审计工单条件。
3. 五步 Runbook：从钉死工具链到压平 flaky
- 钉死 Xcode 与
DEVELOPER_DIR：在专有 Mac Runner 上使用显式sudo xcode-select -s或由基础设施注入统一路径；在任何 PR 模版中要求开发者粘贴xcodebuild -version输出，门禁脚本再比对 semver。这样能消掉九成「我本地预览版你没说」之争。 - 分拆 Job：Smoke / Simulator / Archive 三条泳道：给每条泳道单独的超时、重试与缓存键；避免把「重 Archive」绑在「轻 smoke」后拖垮开发者耐心。泳道参数语言与并发上限可直接复用 PR 并行文的清单。
- 对 DerivedData 设「软预算 + 硬清理」：为磁盘水位设两级阈值：软阈触发降级并发，硬阈触发
rm -rf与冷启动；把每次清理写进指标，避免「为什么忽然全员排队」这种神秘事件。 - 对并发错误设「可诊断日志包」：当
-warn-concurrency或完整模式失败时，自动打包swiftc依赖图片段、关键模块接口文本与 Runner 资源视图；要求修复 PR 必须附该包，减少来回三次都找不对模块的尴尬。 - 把「允许的不完美」写进 ADR：若必须暂时保留
nonisolated(unsafe)或与第三方类型共存，记录在架构决策表里：负责人、复盘日期、风险半径。半年后机器人自动开 issue——这比口头承诺更接近工程真实。
你可以在 CI YAML 中用类似片段强调工具链对齐（节选示意，占位符请改成团队 scheme）：
4. 硬核参数：阈值、时间与磁盘水位
- 冷启动首开墙钟时间：在专有 M4／统一内存节点上，100k LOC 量级主工程的首次
swift build建议压到不大于 420 秒（若长期飘高，多半是并发任务抢同一 NVMe——应回到 Job 分拆表）。该数字为经验阈值，请以你团队 backlog 校准。 - Archive Job 独享窗口：为归档任务独占 1–2 P-core 等量算力配额，避免与它共享机器的 UI Smoke 争抢同一温控预算；这比盲目加并行度更能降低 flaky。
- DerivedData 软阈：单节点 DerivedData不大于 240 GB（或磁盘的 70%）触发自愈清理脚本；写入 launchd plist 或由 Runner 钩子触发。
- 门禁复跑策略：对确认为资源争用所致的失败，只允许同一代码哈希下复跑最多 1 次，防止「无限重骰」掩盖真正的数据竞争。
若同时使用 Xcode Cloud 与专有 Runner，请参阅对照文「接缝」：强定制脚本、长期缓存或对磁盘布局苛求的归档，通常落到可 SSH 的专用 Mac。
5. 站内交叉索引与延伸阅读
在阅读顺序上可先读：三种算力来源 定 SLA，再对照 Simulator 并行；最后再用本文门禁拆模块——避免队列与归档抢同一条流水线。
6. 选型收束：为什么 Mac 独占云胜过混杂池
一些团队把 Job 投进共享温控与盘的「泛 Mac 池」，短期账单好看，但一旦并发诊断与 flaky 归档搅在一起，排障时间会上升：拿不到独占 NVMe／稳定队列／可预期温控，就难以分清告警来自代码还是邻机噪声。专门为 Apple 工具链调校的 Mac 云更接近办公室自建 Runner：**独占算力 + 漂移少 + SSH 习惯可沿用**；在混杂池上与邻机抢 IO，只会累积不可测的技术债。