Golang环境构建

发表于   |   分类于

搭建一个Golang开发环境，并理解一些相关的基础知识。关于Go安装及IDE的内容本文不会涉及。

Golang环境配置

环境变量配置

GOROOT

Golang的安装目录，默认为C:\go或/usr/local/go，$GOPATH/bin下有各种工具，通常会自动加入到$PATH变量中，从而可以全局使用各种golang的命令。

GOPATH

Golang项目的开发工作区，默认为%USERPROFILE%\go或$home/go，$GOPATH不能与$GOROOT相同，可以设置多个工作区，如GOPATH=/opt/go;$home/go。

项目目录

一个常见的go项目目录如下：

1
2
3
4
5
6
7
8
9
10
11
bin/
src/
    config/
        config.go
    hello/
        hello.go
    test/
        test.go
pkg/
install.bat
install.sh

bin：编译生成的可执行文件目录。
src：源码目录。
pkg：编译生成的包、库静态文件，根据操作系统及CPU架构区分不同目录。

基于GOPATH的依赖管理

在golang 1.11之前，被诟病得最多的是其极弱的包依赖管理功能：

  • 依赖包需用go get手动下载。
  • 所有依赖包和项目都放$GOPATH/src，如C:\go\src\company\foo\bar与依赖的包C:\go\src\github.io\x\y在同一个父目录下，比较混乱。
  • 依赖包没有版本概念，因此协作开发时，需将各成员本地$GOPATH/src的包统一，或使用第三方包管理工具所依靠的vendor目录。
  • 若部分依赖包依赖于已经失效的包，比如在github上已经更换地址，需要手动修改该依赖包的依赖。

下文会介绍用于改善这种状况的go module。

GOBIN

通常是$GOPATH/bin，指向可执行文件的目录。

GOOS与GOARCH

当前操作系统和CPU架构，这两个环境变量涉及到交叉编译。

交叉编译

即在当前环境编译不同操作系统及CPU架构的可执行文件，如：
GOOS=linux GOARCH=amd64 go build main.go
则编译为linux-amd64的可执行文件。

常用go命令

go build

用于测试编译过程，如有必要会编译关联的包。

  • 如果编译普通包，不会有任何效果。
  • 如果编译main包，格式形如go build <项目名>/<package>，会在当前路径下生成一个当前环境的可执行文件，如果带上-o参数则生成到指定的路径。
  • 如果只想编译单个go文件，在go build后加上文件名。
  • 会忽略_及.开头的go文件。

go clean

移除当前源码包里面编译生成的文件。

go fmt

等同于gofmt -w命令，用于将代码格式标准化。

go get

动态获取远程包，是下载包和go install两步的结合。

go install

编译包，如有必要会编译关联的包。

  • 如果编译普通包，在pkg目录下生成静态文件（.a文件）。
  • 如果编译main包，在bin目录下生成可执行文件。

go mod

在golang 1.12之后，设置环境变量GO111MODULE=on或GO111MODULE=auto:

  • 若设置为on，则使用go module来管理依赖。
  • 若设置为auto，若项目位于$GOPATH/src下，则仍使用旧的依靠GOPATH环境变量的依赖管理模式（即依赖于$GOPATH/src下的各个包），否则与设置为on相同。

接着在项目的根目录使用go mod init <项目名或模块名>生成go.mod文件，则会：

  • 自动下载依赖包且有准确的版本号，下载的包放在$GOPATH/pkg/mod下，可以理解为maven的.m2目录。
  • 可以将项目放到任意路径下，不必再放$GOPATH/src下。
  • 生成的go.mod文件会列出依赖关系。
  • 对于已转移的包，可以用go.mod文件里的replace语句替换，不用再手动改代码里的依赖了。

需要注意：go.mod及go.sum文件需纳入版本控制，从而保持一致防止篡改。

go test

读取源码目录下*_test.go的文件，并编译出测试所需的可执行文件。

go doc

按照包内函数的排序，读取包文档。