先說總結(jié)：
當要安裝新的第三方SDK而不像改變其他已經(jīng)安裝的第三方SDK版本的時候用 pod install.而當你想改變已經(jīng)安裝的第三方SDK的版本的時候用pod update.
詳解
1：Podfile.lock和Podfile
當我們新建一個Podfile文件運行后变过，會自動生成一個Podfile.lock文件而芥，Podfile.lock文件里存儲著我們已經(jīng)安裝的依賴庫(pods)的版本再姑。
當我們第一次運行Podfile時高帖，如果對依賴庫不指定版本的話，cocoapods會安裝最新的版本锦秒，同時將pods的版本記錄在Podfile.lock文件中露泊。這個文件會保持對每個pod已安裝版本的跟蹤，并且鎖定這些版本旅择。如pod 'AFNetworking', '2.0' //只使用2.0版本惭笑。
2：pod install
用于工程中第一次取回pods，也用于每次編輯Podfile添加、更新或移除pod時沉噩。
當你下次執(zhí)行pod install操作的時候：
1：它只會處理沒有被記錄在Podfile.lock文件中的pods的依賴捺宗。
2：對于已經(jīng)記錄在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版本的最新版本游昼。(執(zhí)行 pod outdated檢查版本速度有些慢甘苍，需要一些時間)這意味著如果你對這些pod運行pod update PODNAME，它們將會更新——只要這些版本仍然滿足如pod ‘MyPod’, ‘~>x.y’這樣設(shè)置在Podfile中的約束烘豌。
5：注意
綜上所述载庭，除非你的策略是不能提交Pods文件夾到共享倉庫，否則你應(yīng)該總是提交并推送你的Podfile.lock文件廊佩。
否則囚聚，你將會打破上述關(guān)于pod install將會鎖定你的pods的已安裝版本的整個邏輯。
使用場景1
用戶1創(chuàng)建了一個工程标锄，并想使用pods A顽铸、B、C料皇。他創(chuàng)建了這些pods的Podfile谓松，然后運行pod install。
這將會安裝pods A践剂、B鬼譬、C，我們假定它們都是版本1.0.0.
Podfile.lock文件將會持續(xù)跟蹤逊脯，并記住A优质、B和C都已經(jīng)安裝為版本1.0.0。
備注：安裝新的SDK用pod install。另外盆赤，由于這是第一次運行pod install贾富，并且Pods.xcodeproj工程并不存在，該命令也會創(chuàng)建Pods.xcodeproj和.xcworkspace牺六，但這只是該命令的副作用而非主要功能颤枪。
使用場景2
隨后，用戶1想要添加pod D到他們的Podfile淑际。
他們在這之后也應(yīng)該運行pod install畏纲，因此即使pod B的維護者在第一次執(zhí)行pod install之后發(fā)布了版本1.1.0，這個工程也將繼續(xù)使用版本1.0.0——因為用戶1只想要添加pod D春缕，而不想有意外的更新了pod B的風險盗胀。
使用場景3
然后用戶2，一個以前從未參與過這個工程的人锄贼，加入到團隊之中票灰。他克隆了倉庫，然后使用pod install宅荤。
Podfile.lock文件（應(yīng)該被提交到git倉庫中）的內(nèi)容會保證用戶2能獲得完全相同的pods屑迂，以及與用戶1使用的完全相同的版本。
盡管pod B的1.1.0版本現(xiàn)在已經(jīng)可用冯键，用戶2仍將獲得pod B的1.0.0版本惹盼。因為這就是寫在Podfile.lock中的內(nèi)容。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(chǎn)’, ‘1.0.0’，就能夠保證團隊中的其他人擁有相同的版本前翎。
然后他們即使使用了pod update稚配，即使添加了新的pod，認為這將不會有更新到其他pods的風險港华，因為他們已經(jīng)在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的維護者可能在這段時間里發(fā)布了新的版本）逻住。
這就是為什么確保每一個團隊成員都能在各自的電腦上使用相同版本的pod庫的唯一方法就是使用Podfile.lock，并且正確的使用pod install和pod update迎献。
其他相關(guān)
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的版本，寫這個限制和什么都不寫是一個效果吁恍，都表示使用
關(guān)于CocoaPods的spec倉庫
無論是執(zhí)行pod install還是pod update的時候會升級CocoaPods的spec倉庫扒秸。導(dǎo)致更新速度變慢。
使用一下命令解決
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的版本號
