Swift Package Manager 系列 05｜在 iOS 项目里接入和管理第三方 Package 的经验

很多人谈第三方依赖管理时，关注点都比较前置：

• 这个库能不能通过 SPM 接入
• Xcode 能不能识别
• 版本号怎么写

这些当然重要，但在真实项目里，真正的成本往往不是接进来那一刻，而是它接进来之后的几年。

因为第三方依赖一旦进入项目，就会带来一整串长期问题：

• 升级节奏怎么控制
• API 变化会影响哪些模块
• 是否把具体库直接暴露到了业务代码
• 一旦想替换库，代价会不会很大

所以“管理第三方 Package”真正难的，不是安装，而是治理。

一、接第三方依赖前，先问的不是“好不好用”，而是“它会不会进入核心边界”

一个库进项目前，我最先问的通常不是：

• star 多不多
• 文档漂不漂亮

而是：

• 它会不会直接进入大量业务代码
• 它会不会定义我们未来的某类接口形状
• 它一旦升级或替换，会影响多大范围

因为有些库只是外围能力，比如调试工具、日志后端、一次性小工具；
有些库则会直接进入系统核心，比如网络层、图片层、路由层、存储层。

后者一旦选型失误，后面改动成本会非常高。

所以我更关心它进入的是“边缘层”还是“主干层”。

二、不要让业务代码直接认识第三方库太多细节

这是我觉得最容易被忽略，但最关键的一条经验。

假设你用了某个图片加载库，如果项目里到处都是它的 API：

• View 层直接 import
• ViewModel 也知道它的类型
• 工具层也依赖它

那这个库很快就会从“依赖”变成“基础设施的一部分”。
你将来想升级它、替换它，成本会远超预期。

所以更稳的做法通常是：

• 在合适的边界上包一层自己的抽象
• 让业务依赖你的能力接口，而不是依赖库本身

这不意味着任何第三方库都必须全量包一层，但至少对那些会深入主干层的依赖，应该认真考虑隔离。

三、SPM 让接入更容易，但也容易让“顺手加一个依赖”这件事变得过于轻率

这是一个很现实的副作用。

因为 SPM 接入太顺手了，很多团队会慢慢养成这种习惯：

• 看到一个小需求
• 搜一个库
• 加进去
• 反正也就一个 package

短期看很高效，长期问题会逐渐累积：

• 依赖数量膨胀
• 编译链变长
• 某些库长期无人维护
• 多个库功能重叠
• 项目里开始出现很多“谁也说不清为什么还在”的依赖

所以 SPM 让依赖管理更轻了，但轻不等于该放松治理标准。
越轻的工具，越需要人为把关。

四、版本管理的核心，不是怎么写范围，而是升级策略是否清楚

很多人学 SPM 版本时，会先关注：

• 精确版本
• 范围版本
• upToNextMajor

这些规则需要知道，但工程上更重要的问题其实是：

• 这个依赖是谁负责升级
• 多久审视一次版本
• 升级是跟着业务需求走，还是定期治理
• 升级失败时怎么快速评估影响面

如果这些事情没人负责，那么你写得再漂亮的版本约束，最后也只会变成“几年没动过的固定值”。

所以依赖版本管理本质上不是语法问题，而是治理节奏问题。

五、第三方依赖最怕的不是“用错”，而是“进入系统后没人再看”

很多依赖引入那天大家都很认真，之后就再也没人管了。
这会带来几个典型风险：

• 安全更新长期落后
• API 变化积压到一次升级爆炸
• 团队里没人知道这个库到底还被谁依赖
• 同类能力库不断叠加

于是项目会慢慢进入一种状态：

• 依赖不是不能用
• 但谁也不太敢动

这比“当初选错一个库”更常见，也更难处理。

六、我更看重的是依赖清单是否“可解释”

一个健康的项目依赖清单，不一定很短，但最好是可解释的。

也就是说，你拿起某个依赖时，团队能说清楚：

• 它解决什么问题
• 为什么是它
• 它位于哪一层
• 是否有隔离边界
• 如果未来要替换，代价主要在哪里

如果一个依赖已经变成：

• “以前就有”
• “好像哪里在用”
• “删了怕出事”

那它其实已经进入了治理失控区。

七、一个实用策略：把第三方依赖分层看待

我通常会把依赖分成三类：

1. 边缘型依赖

例如某些开发辅助、日志上报、低频工具。
这类依赖即使用得比较直接，风险也相对可控。

2. 平台型依赖

例如图片、网络、存储、路由等。
这类依赖很可能进入系统主干，更应该认真控制暴露范围。

3. 可替换性很弱的深耦合依赖

有些库一旦接入，就会影响大量 API 设计。
这种依赖最需要在一开始就想清楚边界，不然未来替换成本会非常高。

这种分层思路比“一律直接用”或者“一律全包一层”都更现实。

八、结论：第三方 Package 的核心不是接入，而是长期治理

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

在 iOS 项目里管理第三方 Package，真正重要的不是“能不能通过 SPM 装上”，而是“它进入系统之后，你还能不能控制它的边界、升级节奏和替换成本”。

所以依赖管理不是一次性动作，而是一种长期治理能力。