2. 依赖解析原理
好，咱们今天来聊聊依赖解析。说实话，这是SDK发布中最容易翻车的地方之一。我见过太多团队，代码写得漂漂亮亮，结果一发布，用户那边依赖冲突炸了锅。嗯，咱们今天就把这块掰开揉碎了讲清楚。
依赖树 vs 依赖图：两个不同的视角
先说说依赖树。你想想看，一个SDK依赖了A库，A库又依赖了B库，B库又依赖了C库……这就像一棵树，根是你的SDK，叶子是那些最底层的依赖。每个节点只有一个父节点，路径是唯一的。
但实际项目中，事情没那么简单。我遇到过这种情况：SDK依赖了A和B，结果A和B都依赖了C，但版本不同。这时候依赖树就变成了依赖图——一个节点可能有多个父节点。说白了，树是理想情况，图才是现实。
核心区别：依赖树假设每个包只被一个上层依赖引用，依赖图则允许多个引用。实际项目中，99%的情况都是依赖图。
版本范围与语义化版本
语义化版本，说白了就是 主版本.次版本.补丁 这套规则。我个人习惯是：
- 主版本：不兼容的API变更。我改了这个，你就得改代码。
- 次版本：向下兼容的新功能。加个新接口，旧的还能用。
- 补丁：向下兼容的问题修复。修了个bug，你啥都不用动。
版本范围怎么写？常见的有这么几种：
| 写法 | 含义 | 示例 |
|---|---|---|
^1.2.3 |
兼容主版本1，允许次版本和补丁升级 | 1.2.3 ~ 1.x.x |
~1.2.3 |
兼容次版本2，允许补丁升级 | 1.2.3 ~ 1.2.x |
>=1.2.3 <2.0.0 |
精确范围 | 1.2.3 ~ 1.999.999 |
1.2.3 |
锁定版本 | 必须精确匹配 |
我的建议：SDK发布时，尽量用 ^ 范围。太宽了容易出兼容问题，太窄了用户升级困难。我踩过坑——有一次锁死了补丁版本，结果用户想修个安全漏洞都升不了级。
依赖冲突的根源
为什么会冲突？说白了就一个原因：同一个包，不同版本，同时被需要。
我举个例子。你的SDK依赖了 logger@^1.0，用户的项目依赖了 logger@^2.0。这两个版本不兼容，但你的SDK和用户的项目都得用logger。怎么办？
常见的冲突场景有三种：
- 传递依赖冲突：A依赖C@1.0，B依赖C@2.0，你的SDK同时依赖A和B。
- 直接依赖冲突：用户的项目和你的SDK依赖了同一个包的不同版本。
- 间接依赖冲突：你的SDK依赖了A，A依赖了C@1.0；用户依赖了B，B依赖了C@2.0。C的版本冲突了。
注意：我曾经遇到过一个案例——SDK依赖了 requests@^2.0，用户项目依赖了 requests@^1.0。两个版本API签名完全不同，结果运行时直接报 AttributeError。排查了整整两天才发现是依赖冲突。
解决冲突的思路其实不复杂：
- 方案一：升级依赖。把你的SDK依赖的版本范围放宽，或者升级到兼容版本。
- 方案二：依赖隔离。用虚拟环境、命名空间或者打包工具把依赖隔离开。
- 方案三：锁定版本。在发布时明确声明你测试过的版本组合。
我个人更推荐方案一。为什么呢？因为依赖隔离会增加用户的使用成本，锁定版本又太死板。把依赖升级到兼容版本，才是长久之计。
嗯，依赖解析这块，说白了就是「版本管理」的艺术。你想想看，一个SDK可能间接依赖了几十个包，每个包又有自己的版本范围。解析器要做的，就是在这张复杂的依赖图中找到一个「大家都满意」的版本组合。如果找不到，那就冲突了。
最后说一句：写SDK的时候，尽量少依赖那些「大而全」的框架。依赖越少，冲突的概率越低。我见过一个SDK，就依赖了三个小工具库，用户集成起来特别顺畅。反而是那些「全家桶」式的SDK，三天两头出冲突问题。
核心原则：依赖越少，冲突越少。每个依赖都要问自己一句——「这个功能我能不能自己实现？」
可可精品资料库