先说总结：
当要安装新的第三方SDK而不像改变其他已经安装的第三方SDK版本的时候用 pod install.而当你想改变已经安装的第三方SDK的版本的时候用pod update.
详解
1：Podfile.lock和Podfile
当我们新建一个Podfile文件运行后，会自动生成一个Podfile.lock文件，Podfile.lock文件里存储着我们已经安装的依赖库(pods)的版本。
当我们第一次运行Podfile时，如果对依赖库不指定版本的话，cocoapods会安装最新的版本，同时将pods的版本记录在Podfile.lock文件中。这个文件会保持对每个pod已安装版本的跟踪，并且锁定这些版本。如pod 'AFNetworking', '2.0' //只使用2.0版本。
2：pod install
用于工程中第一次取回pods，也用于每次编辑Podfile添加、更新或移除pod时。
当你下次执行pod install操作的时候：
1：它只会处理没有被记录在Podfile.lock文件中的pods的依赖。
2：对于已经记录在Podfile.lock中的pods，会下载记录在Podfile.lock文件中的准确版本，而不去检查是否有新版本可用。即一直保持初始版本。
3：对于没有记录在Podfile.lock文件中的pods，会查找匹配Podfile中描述的版本（如pod 'AFNetworking', '2.0' ）。当没有指定版本号时就下载当前最新的版本，并将版本号记录在Podfile.lock中。
3：pod update
当你运行pod update PODNAME命令，CocoaPods将会尝试找到PODNAME指定pod的更新版本，而不会顾及Podfile.lock文件中记录的版本。它将会更新pod的最新可用版本（只要满足Podfile中的版本约束）。
如果你运行pod update而不带pod名称，CocoaPods将会更新Podfile文件中记录的每一个pod到约束条件下最新可用版本。
4：pod outdated
当你运行pod outdated命令，CocoaPods会列出所有你Podfile.lock文件中记录的SDK版本的最新版本。(执行 pod outdated检查版本速度有些慢，需要一些时间)这意味着如果你对这些pod运行pod update PODNAME，它们将会更新——只要这些版本仍然满足如pod ‘MyPod’, ‘~>x.y’这样设置在Podfile中的约束。
5：注意
综上所述，除非你的策略是不能提交Pods文件夹到共享仓库，否则你应该总是提交并推送你的Podfile.lock文件。
否则，你将会打破上述关于pod install将会锁定你的pods的已安装版本的整个逻辑。
使用场景1
用户1创建了一个工程，并想使用pods A、B、C。他创建了这些pods的Podfile，然后运行pod install。
这将会安装pods A、B、C，我们假定它们都是版本1.0.0.
Podfile.lock文件将会持续跟踪，并记住A、B和C都已经安装为版本1.0.0。
备注：安装新的SDK用pod install。另外，由于这是第一次运行pod install，并且Pods.xcodeproj工程并不存在，该命令也会创建Pods.xcodeproj和.xcworkspace，但这只是该命令的副作用而非主要功能。
使用场景2
随后，用户1想要添加pod D到他们的Podfile。
他们在这之后也应该运行pod install，因此即使pod B的维护者在第一次执行pod install之后发布了版本1.1.0，这个工程也将继续使用版本1.0.0——因为用户1只想要添加pod D，而不想有意外的更新了pod B的风险。
使用场景3
然后用户2，一个以前从未参与过这个工程的人，加入到团队之中。他克隆了仓库，然后使用pod install。
Podfile.lock文件（应该被提交到git仓库中）的内容会保证用户2能获得完全相同的pods，以及与用户1使用的完全相同的版本。
尽管pod B的1.1.0版本现在已经可用，用户2仍将获得pod B的1.0.0版本。因为这就是写在Podfile.lock中的内容。pod B被Podfile.lock文件锁在了1.0.0版本（因此这个文件叫这个名字）。
使用场景4
后来，用户1想要检查这些pods是否有更新可以用。他运行了pod outdates，这个命令会告诉他pod B有新的1.1.0版本且pod C有新的1.2.0版本。
用户1决定他们要更新pod B，但是不更新pod C；因此他运行pod update B，让B从版本1.0.0升到版本1.1.0（同时Podfile.lock文件也随之更新），但是将pod C保持在1.0.0版本（不会更新到1.2.0）。
使用场景5
有些人可能想通过在他们的Podfile中指定pods的准确版本号，如pod ‘a’, ‘1.0.0’，就能够保证团队中的其他人拥有相同的版本。
然后他们即使使用了pod update，即使添加了新的pod，认为这将不会有更新到其他pods的风险，因为他们已经在Podfile中绑定到指定的版本了。
但实际上，这不足以保证我们在上面场景中提到的用户1和用户2总能得到所有pods的相同版本。
一个典型的例子是，如果pod A依赖了A2——在A.podspec中有声明dependency ‘A2’, ‘~> 3.0’。此时，在Podfile中使用pod ‘A’,’1.0.0’，确实会强制用户1和用户2都总是使用pod A的1.0.0版本，但是：
用户1可能最后得到pod A2的3.4版本（因为这是A2那时的最新版本），而当用户2在之后加入工程运行pod install时，他可能得到pod A2的3.5版本（因为A2的维护者可能在这段时间里发布了新的版本）。
这就是为什么确保每一个团队成员都能在各自的电脑上使用相同版本的pod库的唯一方法就是使用Podfile.lock，并且正确的使用pod install和pod update。
其他相关
pod的写法
pod 'AFNetworking' //不显式指定依赖库版本，表示每次都获取最新版本
pod 'AFNetworking', '2.0' //只使用2.0版本
pod 'AFNetworking', '> 2.0' //使用高于2.0的版本
pod 'AFNetworking', '>= 2.0' //使用大于或等于2.0的版本
pod 'AFNetworking', '< 2.0' //使用小于2.0的版本
pod 'AFNetworking', '<= 2.0' //使用小于或等于2.0的版本
pod 'AFNetworking', '~> 0.1.2' //使用大于等于0.1.2但小于0.2的版本
pod 'AFNetworking', '~>0.1' //使用大于等于0.1但小于1.0的版本
pod 'AFNetworking', '~>0' //高于0的版本，写这个限制和什么都不写是一个效果，都表示使用
关于CocoaPods的spec仓库
无论是执行pod install还是pod update的时候会升级CocoaPods的spec仓库。导致更新速度变慢。
使用一下命令解决
pod install --verbose --no-repo-update
pod update --verbose --no-repo-update
或者
pod install --no-repo-update
pod update --no-repo-update
但是当你长时间不更新spec仓库的时候可能会报错
解决办法 : pod repo update
如何查看当前pods版本号
假如你一直在Podfile中都是裸奔，没有加版本号约束。突然有一天需要查看当前pods版本号的时候。
终端输入: cat Podfile.lock
即可查看当前Podfile.lock中所有pods的版本号