① FAQ：并发、排队与队列策略
Q：共享资源池为什么要限制「同时构建」的数量？
每台远程 Mac 的 CPU、内存与磁盘 IO 有硬上限。若多人同时跑完整 Xcode 归档或大型 Swift Package 解析，容易出现全员变慢、甚至触发 OOM 与磁盘写满，反而比「排队一个一个跑」更慢。因此需要并发上限 + 队列，把峰值削平。
Q：队列用 FIFO 还是分优先级？
默认 FIFO最简单、也最容易向团队解释「谁先提交谁先跑」。在发布窗口可叠加加权公平队列：给「已打 tag / 已审批发布」的任务更高权重，但仍保留饥饿保护（例如等待超过 N 分钟自动升权）。短任务（单测、lint）可走快速通道与重任务隔离，避免被长归档堵死。
② FAQ：配额分配与冲突处理
Q：配额按人还是按项目分更省事？
小团队可采取基线按人 + 弹性按项目：例如每人每日「构建分钟数」或「并发槽位」为基线，主产品在发版周临时调高权重或单独槽位。这样日常公平、发版又不被误伤。与财务对账时也可按项目分摊成本。
Q：两人同时要同一台机子做互斥操作怎么办？
除队列外，对同一工作目录或同一 DerivedData 路径应约定互斥：例如分支命名规范、CI 任务带独占锁、或每人独立构建目录。若用共享 Runner，避免并行写同一 build/；冲突时优先保障已排队最久或已标记发布的任务，其余自动重试或回队列。
③ 可执行阈值示例（并发 / 队列 / 日志）
以下为起步即可用的数值示例，可按机器规格与业务再调；重点是「写进团队文档、可审计」。
| 维度 | 建议阈值 / 策略思路 |
|---|---|
| 单节点重任务并发 | 完整归档 / 大体积编译：同时 1～2 个；若 32GB 内存且常 OOM，先降到 1。轻量任务（lint、单测）可另设 2～4 并行，与重任务分池。 |
| 队列深度告警 | 等待队列 > 5 个重任务时通知负责人；> 10 时评估加节点或错峰。展示「当前位置 + 粗略 ETA」减少重复触发构建。 |
| 公平与抢占 | 同一用户连续占用超过 90～120 分钟可触发「让出一次槽位给队列首位」的软策略（可选）。发布任务可标记 release 优先级，但等待 > 30 分钟的普通任务建议自动升权以防饥饿。 |
| 磁盘与稳定性 | 系统盘或构建盘可用空间持续低于 15% 暂停接收新重任务并告警；配合定期清理 DerivedData / 旧产物（见运维清单）。 |
| 日志保留 | 原始构建日志 7～14 天；聚合指标（成功率、P95 耗时）30～90 天。含敏感输出需脱敏或缩短保留，合规要求单独冷归档。 |
④ 稳定性与运维核对清单
与「连得上」类问题配合阅读：延迟与断线重连配置清单。资源池侧建议每周过一遍下列勾选项。
- □ 并发上限与队列规则已文档化，新成员 onboarding 可读同一份。
- □ 磁盘空间 >15%，清理策略（DerivedData、旧 artifact）已执行或已自动化。
- □ 队列深度、失败率、P95 等待时间有面板或日志可查；异常有告警接收人。
- □ 发布期配额/优先级已提前调整，冲突处理顺序（发布 > 长队 > 可重试）团队已知悉。
- □ 日志保留周期与脱敏规则符合内控；需要时可追溯至具体构建 ID。
⑤ 小结
共享池 · 排队 · 配额
用 MeshMac 落地资源池与多节点，少冲突、好运维
免登录即可查看方案与下单；结合站内协作与队列类文章，把小团队共享 Mac 的并发与配额一次理顺。
多用户共享
排队与配额
稳定运维