图中高亮出来的就是 Build 号，如果你的界面没有显示的话，请按住 Command 键然后鼠标左键点击该位置，就会显示。
说到项目的 Build 号，这个其实很少有人关注过，因为通常它就是一些字符串和一个数字拼起来的，就像ABCD1234一样普通、直白。而为什么是需要一个数字呢？
就以某一款 App 为例吧，通常只要是比较有追求的程序员，在某种程度上都会比较懒，懒得做重复性的工作，比较一会儿在某个界面上一通点，然后给测试打了一个包，过了不久一会又要做类似的事情，而且一直重复着这些动作。因为程序员都是抱着代码改变世界的理想来的，你就让他做个这？
很快就有人说，让这些重复的工作自动化起来，每次提交了代码之后让持续集成服务器（CI Server）自动打个包放那，谁爱要谁自己去取。用什么来标识每一个包呢？
首先，必须能够唯一标识每一个包；其次，最好不用人为的每次去修改，因为改的人多了难免会重复；最后，给我两个包我还要能够识别出来哪个新哪个旧。为了满足这些条件，自然数就成为了首选目标。能够方便的自增，不同背景的人沟通起来也没什么障碍。另外时间戳也是个不错的选择（不过说到底时间戳也还是一个数字），但涉及到时区的问题，有些时候很容易让人感到疑惑。
之所以很少有人关注这个 Build 号，是因为一般情况下不用关心它，即使有时候使用的内测版本的应用有问题，基本上都有一键上传日志的功能，Build 号一般都包含在上传的日志中了。然后系统就有能力自己根据 Build 号进行日志的分类了。
可能有人就会问了，我们不是还有版本号吗？为什么不直接用版本号表示 Build 呢？当然也有这么干的，甚至还有直接把 Build 号和版本号合二为一的。不过我不建议这么做，毕竟让一样东西具有多种职责，本身就违反了我们常说的单一职责原则（SRP）。有时候，它带来的弊端可能在当时没有显现出来，但出来混总是要还的，自己不还就是别人还。
综上所述，直接使用版本号或者合二为一来表示每一次构建，也不是太好。既然不好，索性就分开，直接用一个简简单单的自然数来表示每一次的 Build 号。反正这个 Build 号机器关心的多，人关心的少。
那么反过来问题又来了，我们都有 Build 号了，为什么又要弄出一个版本号呢？且听下回分解。
