当我们的项目比较大、使用的第三方的库多了以后，执行pod update命令偶尔就会出现类似这样的错误：
[!] Unable to satisfy the following requirements:
\- ‘A (=2.0)’ required by ‘Podfile’
\- ‘A’ required by ‘B’
\- ‘A (~> 1.4)’ required by ‘C (1.6)’
这个错误信息很简单有很让人费解，我们仅仅知道 pod 无法满足我们的需求，但是是什么需求？没有说啊ಥ_ಥ.
其实事情的真相是各种不同的库以及 podfile 本身对于某一个库的版本要求出现了冲突，导致 pod 不知道应该做些什么，因此启只好无奈的把这些冲突的地方都写出来，让开发者进行处理。
在开头的那段错误 log 想要表达的意思是：开发者在 Podfile 中要求 A 是 2.0 版本，而 B 要求 A 是最新的版本，最要命的 C 竟然要求 A 是大于1.4但是小于2.0的版本，这里和最开始 podfile 的版本要求起了冲突，导致pod 无法进行正常的库管理。
那么在这种情况下我们可以首先尝试把 C 更新到当前最新的版本，因为很有可能 C 库的开发者已经更改了对于 A 的依赖的版本规则；如果不行，我们要么得去 clone 出来一个自己的 C 然后去修改 podspec，要么就是换用其他的和 C 类似的库来解决版本冲突问题，要么就是更改 podfile 以及回退 B 的版本，让A 的某一个版本同时存在于 Podile 、B、C 的版本要求的交集中。
另外，在 pod 的0.35版本中已经做了一些对于冲突解决的优化，举个例子：
pod ‘ A’ # Version 2.0.0 activates AFNetworking with: >= 2.0.0 && < 3.0.0
pod ‘B’ # Version 2.1.0 activates AFNetworking with: >= 2.2.0 && < 3.0.0
pod ‘C’ # Version 0.1.2 activates AFNetworking with: >= 1.3.0 && < 2.0.0
这样的版本要求在0.35之前是会报出文章最开头的那个错误的，但是0.35以后，pod 会把 A、B回退到一个要求 AF 的版本范围为 1.x 到 2.x 的版本。
