其实这个问题是昨天遇到的，原来觉得很简单，没有什么必要写，这两天应用在等待审核，还是写一下吧，万一能帮到有需要的人呢，正好也加深一下自己的记忆。
一般平时我们使用第三方库的时候都是需要什么版本就导入什么版本的库就行了，不会像我这样一个一个版本去试，但是不怕一万，就怕万一遇到了呢。
因为我们项目中使用到了一个比较特殊的库ProtocolBuffers，至于库是做什么的我就不多介绍了，需要用的人自己会去了解，不需要用到的人怎么都不会用到，因为这个需要后台的配合使用，所以在使用的过程中对这个库的版本有一定的要求，必须要和服务器使用的版本对应起来，不然服务器给出的结构体就会出现报错的现象。
废话不多书，情况是这样的，昨天本来像修改一下工程名，所以所有的第三方库都需要重新导入一遍，然后导入的时候没有注意到版本的问题，果然，就发生了上面的问题，一下子导入了最新版本的ProtocolBuffers，然后结构体就报错了，几百个红点，爽死人，由于当时忘记了服务器使用的是什么版本的ProtocolBuffers，但是服务器的小伙伴也挺忙的，就不想去打扰他们帮我看一下了，其实这个自己也可以看到，打开服务器给出的结构体的swift文件（我们项目是使用swift编写的，我也不知道ProtocolBuffers有没有oc版本，需要的小伙伴可以去查官方文档），在代码最上面的注释信息中就可以看到生成这个结构体代码的ProtocolBuffers版本，这里我更新的ProtocolBuffers的最新版本是3.0.22，但是看到这个结构体的版本是3.0.13，所以要解决这些报错，我们就需要将ProtocolBuffers的版本pod到3.0.13去。
然后，根据习惯，去修改了podfile文件中的ProtocolBuffers的版本好，然后pod update，完了以后，结果发现，当前ProtocolBuffers的版本还是3.0.22，当时就懵逼了，然后检查对应的文件，打开podfile.lock文件，才发现，原来这个文件里面的版本还是3.0.22，问题就出现在这里，所以修改了这个文件里面的版本以后，重新更新库文件，然后就更新下来了3.0.13版本的ProtocolBuffers。然后编译，通过，成功运行了项目。
这个问题就解决了。
这里解释一下Podfile和Podfile.lock这两个文件的作用：
当我们第一次pod完需要的库的时候，pod就会自动为我们创建一个Podfile.lock文件，这个文件就相当于一个本地化的副本，我们每次执行拉取操作的时候，都会根据这个文件进行快速的拉取，所以这个文件才是我们最终拉取的需要的库的文件记录，如果我们修改了Podfile这个文件之后拉取需要的库没有对应上的时候，就去检查一下Podfile.lock这个文件，对应修改以后重新拉取就可以了。
