在 Linux 上你习惯把依赖缓存与构建输出分卷；换到 macOS 共享节点，SwiftPM 的源码检出目录、Pods 目录与 DerivedData 往往默认落在同一用户家目录树下，若再叠加多个仓库并行，磁盘与 inode 会先於 CPU 成为瓶颈。下面七条用于评审前自检。
Package.resolved 与分支策略不一致：同一仓库多分支并行构建时，若未把检出路径与解析结果绑定到「分支桶」，会出现解析成功但链接到错误制品的假阳性。
CocoaPods 的 Ruby 生态漂移：系统 Ruby、rbenv、Bundler 混用导致 pod 版本不一致，表现为「本地绿、CI 偶红」且难以复现。
共享 DerivedData 根目录：多 Job 写入同一 -derivedDataPath 时，模块缓存与索引文件互踩，编译错误看起来像依赖损坏。
Pods 与 SPM 双栈重复拉取：同一第三方既以 Pod 又以 SPM 形式出现，体积与解析时间翻倍，却未必被架构评审发现。
清理脚本误删「仍在队列中的缓存」：定时任务按时间戳删目录，可能删掉正在跑的 Job 的中间产物，引发级联失败。
CDN / 镜像策略不统一：外网抖动时 pod repo update 与 SPM 解析走不同出口，排队时延被放大成「CI 不稳定」。
缺少磁盘水位与只读基线合同：未定义「低于百分之多少触发只读降级或拒绝新 Job」，共享机会在满盘后才暴露，修复成本远高于预防。
这些痛点的共同根因，是把 Linux VPS 上的「单仓库单流水线」假设搬到了「多仓库共享 Mac」：你需要的不只是更大磁盘，而是命名空间化的缓存与锁文件治理。把它们写进台账后，再用下一张表决定：是否值得在工程上收敛为单栈，或接受混用但用分区目录硬隔离。
从依赖管理模型看，SwiftPM 倾向于把可重复解析写进 Package.resolved，强调与编译器同源的解析器；CocoaPods 则长期与 Ruby 工具链绑定，企业里又常以 Bundler 钉死版本。两者混用时，平台侧最忌讳的是「让 CI 用户在交互式 shell 里随手改全局 gem」：那会把不确定性注入每一台共享节点。更稳妥的做法是：每个仓库自带 Gemfile.lock，CI 只执行 bundle exec pod install，并把 vendor/bundle 或等价路径放到可清理分区。
与 可复现构建 篇联动：指纹脚本应同时记录 swift package resolve 的校验和与 pod --version，否则你只锁了 Xcode，却没有锁依赖解析层。与 Runner 篇联动：若你把缓存挂载到共享卷，必须规定「按仓库子目录挂载」而不是「整盘共享一个 DerivedData」，否则并行度越高，互踩概率越大。
解析阶段的网络与 CDN 策略见第 4 节。下面进入对照表，把架构取舍从争论收敛成可执行的分区策略。
没有银弹：只 SPM 时目录结构更统一，但遗留 ObjC 生态仍常依赖 Pods；只 Pods 时团队熟悉，但 Ruby 与 CDN 运维成本更高。评审时把三条 SLA 写清：解析可重复性、磁盘峰值、失败可解释性。
| 维度 | 以 SwiftPM 为主 | 以 CocoaPods 为主 | 混用（常见存量） |
|---|---|---|---|
| 锁文件与可重复性 | Package.resolved 与解析器版本强相关 | Podfile.lock + Ruby/Bundler 版本必须钉死 | 两套锁文件与两套缓存目录，需防重复依赖与路径冲突 |
| 磁盘特征 | 源码检出 + SPM 缓存，体积可预期 | Pods 体积大，Ruby 工具链额外占空间 | 峰值叠加，需分桶 DerivedData |
| 并发友好度 | 目录隔离简单，适合高并行 | pod install 可能长时间占锁，需队列化 | 必须拆分 Job 工作目录，避免同路径写 |
| 运维抓手 | 与 Xcode 工具链同源，易进指纹脚本 | 需维护 gem 源、CDN 与 Bundler 缓存策略 | Runbook 最长，但存量业务最常遇到 |
| 与黄金镜像关系 | 可把 SPM 缓存预热进镜像层 | 常把 Ruby 与已知 Pods 打进基线 | 镜像变大，需分层：工具链层 / 依赖层 / 可变层 |
「像买 VPS 一样租 Mac」在依赖层意味着：你买的是可预期的目录合同与水位线，而不是「和笔记本一样随缘满盘」。把 SPM 与 Pods 的缓存都当成租户，而不是后台噪音。
若你正在实施 企业构建资源池，建议把「依赖解析 Job」与「签名发布 Job」分区：前者可以容忍更激进的清理，后者必须避免与实验性 Bundler 环境共享家目录。与 快照与长期节点 篇联动：混用双栈时，长期节点更依赖「按周清理 + 水位报警」；快照基线则更依赖「把 Bundler 与 SPM 缓存分层预热」。
当评审结论是「短期无法去 Pod，只能混用」时，请把工程规则写死：哪些三方只允许走 SPM、哪些必须留在 Pod（例如尚未 SPM 化的二进制闭源包），并禁止同名模块双通道引入。否则并行编译会在链接阶段才爆炸，排障成本最高。对平台来说，这意味着要在模板仓库里提供最小可复制的 Gemfile 与 .bundle/config 片段，让业务复制粘贴而不是各自发明。
下列顺序强调「先分区、再解析、最后才谈命中缓存」：与 可复现构建 的指纹脚本对齐，避免依赖层引入第二套未记录环境。
为每个仓库固定工作根与分支桶：例如 /ci/work/<repo>/<branch-hash>，所有 SPM 检出、Pods、DerivedData 均落在该桶下，禁止回写到 ~/Library 默认路径。
钉死 Bundler 与 CocoaPods：在 CI 镜像或启动脚本里只使用 bundle exec，并把 BUNDLE_PATH 指到工作桶内的 vendor 目录。
SwiftPM 解析与构建分离观测：对解析阶段单独计时；解析失败时保留 .build 相关日志片段，避免与编译错误混淆。
DerivedData 按 Job 隔离：xcodebuild 统一传入显式 -derivedDataPath，并与上一步工作根组合。
定义清理策略：按水位触发、按队列空闲窗执行、按「最久未访问」淘汰；禁止无差别 rm -rf ~/Library。
与 Runner 标签衔接：对「重 pod install」的 Job 使用独立 label 限流，见 Runner 篇；避免与高频编译 Job 抢同一并发槽。
export CI_WORK_ROOT="/ci/work/${REPO_SLUG}/${BRANCH_KEY}"
export DERIVED_DATA="${CI_WORK_ROOT}/DerivedData"
export PODS_ROOT="${CI_WORK_ROOT}/Pods"
export BUNDLE_PATH="${CI_WORK_ROOT}/vendor/bundle"
mkdir -p "$DERIVED_DATA"
bundle config set path "$BUNDLE_PATH"
bundle exec pod install --deployment
swift package resolve
提示：若同一台机还承担 Fastlane 发布，发布 Job 的工作桶应与 CI 解析桶分离，避免 Bundler 与 App Store Connect 工具链互相污染。
在 GitHub Actions 等平台上，建议把「依赖安装」与「编译测试」分层：缓存键与锁文件内容绑定，而不是只绑定分支名。若使用 Workspace 同时含 SPM 与 Pods，应固定 xcodebuild -workspace 参数，避免本地 GUI 与 CI 命令长期不一致。
与 XCTest / Simulator 篇联动：测试 Job 若复用编译阶段 DerivedData，应显式声明只读或可写范围；否则测试阶段的清理脚本可能误伤编译缓存。把「谁能删谁」写进内部权限模型，和 Linux 上容器卷策略一样严肃对待。
CocoaPods 在企业环境里最典型的生产事故不是语法错误，而是解析阶段外网失败被误判为代码问题。平台应为共享节点配置统一的 gem 镜像与 Git 协议策略（HTTPS/SSH），并在防火墙层允许元数据域名；同时把 pod install 的超时与重试写进 workflow，而不是依赖默认。
SwiftPM 侧则要关注 Package.resolved 是否与解析器版本匹配：升级 Xcode 大版本后，优先在 canary Job 上跑一遍 swift package resolve 与最小构建，再放开全队列。与 可复现构建 的「干净 clone → green build」清单对齐：任何锁文件变更都应触发一次全量解析缓存失效的预警，而不是悄悄污染共享缓存。
注意：不要在满盘临界点继续接受新 Job：应触发只读降级（拒绝调度）并先跑清理；否则 Xcode 与 git 可能出现半写入状态，修复成本远高于短暂停队列。
若团队同时维护多地区节点，建议把 CDN 命中与解析耗时纳入监控面板：当 P95 明显上升时，先怀疑网络与镜像，而不是让业务加「重试三次」式糊墙。与 SSH 接入清单 联动：批量节点的 Bundler 与 pod 版本应通过配置管理下发，而不是手工 SSH 各自升级。
下列条目用于内部对齐；具体阈值以你们并行度与仓库体量为准。
swift package resolve 退出码、bundle exec pod --version 与 Podfile.lock 校验和，作为是否允许合并的门槛。个人笔记本常因睡眠与本地工具链漂移让依赖问题「看起来像玄学」；纯 Linux 又无法承载官方 iOS 工具链。把解析与构建搬到独占、长期在线、可分区的远程 Mac，才能把 SwiftPM 与 CocoaPods 的混用变成合同。相比自建零散机器或混用不稳定托管环境，NodeMini 的 Mac Mini 云端租赁在固定 SSH、清晰磁盘档位与可复制的节点画像上更利于把依赖治理纳入平台工程；需要对比规格与价格时，可先阅读 租赁价格说明，再结合 帮助中心 完成接入。
落地时建议把本 Runbook 与内部「依赖变更等级」绑定：锁文件补丁、次要与大版本升级对应不同审批与缓存失效策略。