Swift Package Manager 系列 06｜什么时候该用 SPM，什么时候还不适合强上

技术社区一旦形成共识，很容易出现另一个问题：
大家开始默认“既然方向对，那就应该尽快全量上”。

SPM 也很容易掉进这个节奏。

它确实是现代 Swift 项目非常重要的工具，但“重要”不等于“任何时候都该立刻全量推进”。
因为工具先进，不代表你当前项目就已经具备承接它的边界和组织条件。

所以我一直不太喜欢那种笼统结论：

• “现在就该全部迁到 SPM”
• “不用 SPM 就落后了”

更实际的问题应该是：

你的项目当前适不适合把某些能力迁到 SPM，以及迁完之后是不是会真的更稳。

一、适合上 SPM 的前提，不是团队想做模块化，而是边界已经开始清楚

如果一个项目目前是这种状态：

• 所有代码高度耦合在一个 App target
• 页面、服务、路由、配置互相穿透
• 公共能力和业务能力边界混乱

那这时候贸然“上 SPM”，很可能只是把现有耦合原封不动搬进多个 Package。

表面上模块化了，实际上依赖关系更难看懂，改起来也更痛苦。

所以我更认同的顺序是：

1. 先让边界开始变清楚
2. 再用 SPM 承载这些边界

而不是反过来，希望 SPM 自动帮你创造边界。

二、什么时候比较适合开始用 SPM

我通常认为下面这些信号说明项目已经比较适合引入或扩大 SPM：

• 有明确的公共能力模块可以独立出来
• 团队已经开始有边界意识，而不是只按目录分代码
• 某些能力值得独立测试和独立演进
• 主工程已经因为膨胀出现明显维护成本
• 团队愿意为模块边界承担额外设计成本

如果这些条件逐渐出现，SPM 往往会很自然地变成下一步。

三、什么时候不适合“强上”

这里的“强上”，不是说完全不用，而是指那种把 SPM 当作政治任务式推进。

以下几种情况，我会非常谨慎：

1. 项目还很小，主要痛点根本不是模块边界

如果当前项目就几个人、规模不大、边界也相对简单，最主要问题可能压根不是模块化。

这时过早引入一堆 Package，带来的复杂度可能比收益还大。

2. 团队对边界还没有基本共识

如果大家现在连：

• 基础层和业务层怎么分
• 页面层和服务层怎么分
• 公共模块和宿主模块怎么分

都还没有共识，那 SPM 只会把这些争议提前暴露，但不一定能解决它们。

3. 只是为了“看起来先进”

这是最危险的一类动机。
如果采用 SPM 的理由只是：

• 别人都在用
• 架构图会更好看
• 简历上更现代

那大概率最后会变成“形式升级，结构不变”。

四、SPM 最容易被高估的地方：以为它会自动带来好架构

它不会。

SPM 的强项是：

• 承载模块边界
• 显式化依赖关系
• 让模块演进更自然

但它不会替你回答：

• 哪个模块值得存在
• 依赖方向该怎么设计
• 公共层是否抽早了
• 某些业务代码是不是本来就不该独立

也就是说，SPM 更像一块好地基，而不是建筑师。
没有设计意识，换了新地基也一样会盖出复杂结构。

五、迁移策略比“要不要迁”更重要

很多项目不是输在“不该迁”，而是输在“迁法太猛”。

一个更稳的迁移策略通常是：

• 先从边界最清楚的模块试点
• 先做少量高确定性的拆分
• 跑几个迭代，验证依赖和协作成本
• 再决定是否继续扩大

而不是一上来就：

• 全仓库拆包
• 所有公共代码强制进入 Package
• 一次性迁移所有第三方依赖

模块化是长期工程，不适合一波梭哈式推进。

六、一个实用判断标准：用了 SPM 之后，项目会更清楚还是更绕

如果一个改动在迁完之后：

• 依赖方向更清晰
• 模块职责更明确
• review 时更容易判断影响范围
• 测试边界更自然

那这次迁移大概率是值得的。

如果迁完之后：

• 模块更多了但职责没更清楚
• 宿主工程仍然知道一堆内部实现
• 改一个功能要跨多个包来回跳

那说明问题不在工具，而在边界设计本身。

七、结论：SPM 值得用，但不值得用成一场形式主义迁移

如果只用一句话总结，我会说：

什么时候该用 SPM，关键不在“它是不是正确方向”，而在“你的项目和团队当前是否已经准备好用模块边界来承载复杂度”。

所以真正稳的做法不是“全量强上”，而是：

• 在合适的时机用
• 从合适的边界开始
• 用来承载已经想清楚的结构

这样 SPM 才会成为减负工具，而不是新一轮工程负担。