再说回来，归档文件的相对目录与 pkg 目录之间还有一级目录，叫做平台相关目录。平台相关目录的名称是由 build（也称“构建”）的目标操作系统、下划线和目标计算架构的代号组成的。
比如，构建某个代码包时的目标操作系统是 Linux，目标计算架构是 64 位的，那么对应的平台相关目录就是 linux_amd64。
因此，上述代码包的归档文件就会被放置在当前工作区的子目录 pkg/linux_amd64/github.com/labstack 中。
（GOPATH 与工作区）
总之，你需要记住的是，某个工作区的 src 子目录下的源码文件在安装后一般会被放置到当前工作区的 pkg 子目录下对应的目录中，或者被直接放置到该工作区的 bin 子目录中。
3. 理解构建和安装 Go 程序的过程构建使用命令go build，安装使用命令go install。构建和安装代码包的时候都会执行编译、打包等操作，并且，这些操作生成的任何文件都会先被保存到某个临时的目录中。
如果构建的是库源码文件，那么操作后产生的结果文件只会存在于临时目录中。这里的构建的主要意义在于检查和验证。
如果构建的是命令源码文件，那么操作的结果文件会被搬运到源码文件所在的目录中。
安装操作会先执行构建，然后还会进行链接操作，并且把结果文件搬运到指定目录。
进一步说，如果安装的是库源码文件，那么结果文件会被搬运到它所在工作区的 pkg 目录下的某个子目录中。
如果安装的是命令源码文件，那么结果文件会被搬运到它所在工作区的 bin 目录中，或者环境变量GOBIN指向的目录中。
这里你需要记住的是，构建和安装的不同之处，以及执行相应命令后得到的结果文件都会出现在哪里。
思考题Go 语言在多个工作区中查找依赖包的时候是以怎样的顺序进行的？
如果在多个工作区中都存在导入路径相同的代码包会产生冲突吗？
这两个问题之间其实是有一些关联的。答案并不复杂，做几个试验几乎就可以找到它了。你也可以看一下 Go 语言标准库中go build包及其子包的源码。那里面的宝藏也很多，可以助你深刻理解 Go 程序的构建过程。
补充阅读 go build 命令一些可选项的用途和用法在运行go build命令的时候，默认不会编译目标代码包所依赖的那些代码包。当然，如果被依赖的代码包的归档文件不存在，或者源码文件有了变化，那它还是会被编译。
如果要强制编译它们，可以在执行命令的时候加入标记-a。此时，不但目标代码包总是会被编译，它依赖的代码包也总会被编译，即使依赖的是标准库中的代码包也是如此。
另外，如果不但要编译依赖的代码包，还要安装它们的归档文件，那么可以加入标记-i。
那么我们怎么确定哪些代码包被编译了呢？有两种方法。
运行go build命令时加入标记-x，这样可以看到go build命令具体都执行了哪些操作。另外也可以加入标记-n，这样可以只查看具体操作而不执行它们。
运行go build命令时加入标记-v，这样可以看到go build命令编译的代码包的名称。它在与-a标记搭配使用时很有用。
下面再说一说与 Go 源码的安装联系很紧密的一个命令：go get。
命令go get会自动从一些主流公用代码仓库（比如 GitHub）下载目标代码包，并把它们安装到环境变量GOPATH包含的第 1 工作区的相应目录中。如果存在环境变量GOBIN，那么仅包含命令源码文件的代码包会被安装到GOBIN指向的那个目录。
最常用的几个标记有下面几种。
-u：下载并安装代码包，不论工作区中是否已存在它们。
-d：只下载代码包，不安装代码包。
-fix：在下载代码包后先运行一个用于根据当前 Go 语言版本修正代码的工具，然后再安装代码包。
-t：同时下载测试所需的代码包。
-insecure：允许通过非安全的网络协议下载和安装代码包。HTTP 就是这样的协议。
Go 语言官方提供的go get命令是比较基础的，其中并没有提供依赖管理的功能。目前 GitHub 上有很多提供这类功能的第三方工具，比如glide、gb以及官方出品的dep、vgo等等，它们在内部大都会直接使用go get。