编译安装包和依赖项

也是编译，与build最大的区别是编译后会将输出文件打包成库放在pkg下

install     compile and install packages and dependencies
go install [-i] [build flags] [packages]

可执行文件安装在由GOBIN环境变量命名的目录中，如果未设置GOPATH环境变量，则默认为[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9JI2pY2J-1605846310736)(https://static.studygolang.com/191006/b46ed6e425e622ef35f3996ab983ba8d)]HOME/go/bin; [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9YSEUri9-1605846310739)(https://static.studygolang.com/191006/51c9c2363e64aa6a344033bacaebae24)]GOROOT/bin或[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ys8tIYlG-1605846310740)(https://static.studygolang.com/191006/7a85f308b8441edf74327ac6772316fa)]GOBIN中

禁用module-aware模式时，其他软件包将安装在目录[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0oJ2heSZ-1605846310741)(https://static.studygolang.com/191006/39934a7eaf8a988547a51602765b9fad)]GOOS_$GOARCH中; 启用module-aware模式时，将构建并缓存其他包，但不安装。-i标志还安装命名包的依赖项

列出包或模块 使用方法

go list [-f format] [-json] [-m] [list flags] [build flags] [packages]

list列出了命名包，每行一个。最常用的标志是-f和-json，它们控制为每个包打印的输出的形式。-f标志

使用包模板的语法指定列表的备用格式，传递给模板的结构形如

type Package struct {
        Dir           string   // 包含包源代码的目录
        ImportPath    string   // 包在目录中的导入路径
        ImportComment string   // package语句的import注释中的路径
        Name          string   // 包名称
        Doc           string   // 包文档字符串
        Target        string   // 安装路径
        Shlib         string   // 包含此包的共享库（仅在-linkshared时设置）
        Goroot        bool     // 这个包在GOROOT目录下吗?
        Standard      bool     // 这个包是标准go库的一部分吗?
        Stale         bool     // `go install`对这个包有什么作用码?
        StaleReason   string   // explanation for Stale==true
        Root          string   // 包含这个包的GOROOT或GOPATH目录
        ConflictDir   string   // $GOPATH中的这个目录shadows dir
        BinaryOnly    bool     // binary-only package (no longer supported)
        ForTest       string   // package is only for use in named test
        Export        string   // file containing export data (when using -export)
        Module        *Module  // info about package's containing module, if any (can be nil)
        Match         []string // command-line patterns matching this package
        DepOnly       bool     // package is only a dependency, not explicitly listed

        // Source files
        GoFiles         []string // .go source files (excluding CgoFiles, TestGoFiles, XTestGoFiles)
        CgoFiles        []string // .go source files that import "C"
        CompiledGoFiles []string // .go files presented to compiler (when using -compiled)
        IgnoredGoFiles  []string // .go source files ignored due to build constraints
        CFiles          []string // .c source files
        CXXFiles        []string // .cc, .cxx and .cpp source files
        MFiles          []string // .m source files
        HFiles          []string // .h, .hh, .hpp and .hxx source files
        FFiles          []string // .f, .F, .for and .f90 Fortran source files
        SFiles          []string // .s source files
        SwigFiles       []string // .swig files
        SwigCXXFiles    []string // .swigcxx files
        SysoFiles       []string // .syso object files to add to archive
        TestGoFiles     []string // _test.go files in package
        XTestGoFiles    []string // _test.go files outside package

        // Cgo directives
        CgoCFLAGS    []string // cgo: flags for C compiler
        CgoCPPFLAGS  []string // cgo: flags for C preprocessor
        CgoCXXFLAGS  []string // cgo: flags for C++ compiler
        CgoFFLAGS    []string // cgo: flags for Fortran compiler
        CgoLDFLAGS   []string // cgo: flags for linker
        CgoPkgConfig []string // cgo: pkg-config names

        // Dependency information
        Imports      []string          // import paths used by this package
        ImportMap    map[string]string // map from source import to ImportPath (identity entries omitted)
        Deps         []string          // all (recursively) imported dependencies
        TestImports  []string          // imports from TestGoFiles
        XTestImports []string          // imports from XTestGoFiles

        // Error information
        Incomplete bool            // this package or a dependency has an error
        Error      *PackageError   // error loading package
        DepsErrors []*PackageError // errors loading dependencies
}

下面记录的其他列表标志控制更具体的细节

go list

模块维护 go mod提供对模块操作的访问，使用方法如下所示

go mod <command> [arguments]

注意，所有go命令都内置了对模块的支持，而不仅仅是“go mod”。例如，日常添加、删除、升级和降级依赖项都应该使用“go get”完成。command列表如下

go mod

下载模块到本地缓存 使用方法如下

go mod download [-json] [modules]

下载命名模块，可以是选择主模块依赖项的模块模式，也可以是path@version格式的模块查询。如果没有参数，download将应用于主模块的所有依赖项

go命令将在正常执行期间根据需要自动下载模块。“go mod download”命令主要用于预填充本地缓存或计算go模块代理

从工具或脚本编辑go.mod 使用方法如下

go mod edit [editing flags] [go.mod]

编辑提供了一个用于编辑go.mod的命令行接口，主要用于工具或脚本。它只读取go.mod，不查找有关模块的信息。默认情况下，edit读取和写入主模块的go.mod文件，但可以在编辑标志后指定其他目标文件。编辑标志指定一些列编辑操作

go mod edit

打印模块需求图 使用方法如下

go mod graph

图以文本形式打印模块需求图(应用的替换)。输出中的每一行都有两个空格分隔的字段：一个模块及其一个需求。每个模块都被标识为path@version格式的字符串，但主模块没有@version后缀

在当前目录下初始化新的模块 使用方法

go mod init [module]

init初始化并将新go.mod写入当前目录，实际上创建一个新的模块，该模块以当前目录为根

添加缺失的模块并移除未使用的模块 使用方法如下

go mod tidy [-v]

tidy确保go.mod与模块中的源代码匹配。它增加了构建当前模块的包和依赖项所需的任何缺少的模块，并且移除未使用的模块。它还将添加任何缺少项的go.sum并删除任何不必要的项

-v标志导致tidy将有关已删除模块的信息打印到标准错误

生成依赖项的自动生成副本 使用说明

go mod vendor [-v]

vendor重置主模块的vendor目录，以包含构建和测试所有主模块包所需的所有包。它不包括vendored的测试代码

-v标志将vendor提供的模块和包的名称打印为标准错误

验证依赖项是否具有预期内容 使用说明

go mod verify

验证检查当前模块(存储在本地下载的源缓存中)的依赖项在下载后是否未被修改。如果所有模块都未修改，验证打印“all modules verified.”，否则它报告哪些模块已被更改，并导致“go mod”以非零状态退出

解释为什么需要包或模块 使用说明

go mod why [-m] [-vendor] packages...

why在导入图中显示从主模块到列出的每个包的最短路径。如果给定了-m标志，why将参数视为模块列表，并在每个模块中找到指向任何包的路径。默认情况下，why查询与“go list all”匹配的包的graph，其中包括可访问包的测试。-vendor标志导致排除依赖项测试的原因

编译并运行go程序 使用说明

go run [build flags] [-exec xprog] package [arguments...]

run编译并运行名为main的go包。通常，包被指定为来自单个目录的.go源文件列表，但它也可能是与单个已知包匹配的导入路径、文件系统路径或模式，如“go run.”或“go run my/cmd”

默认情况下，“go run”直接运行编译后的二进制文件：“a.out arguments…”。如果给定了-exec标志，“go run”使用xprog调用二进制文件xprog a.out arguments...

测试包

运行当前包目录下的tests

常用命令如: go test或go test -v

test packages
go test [build/test flags] [packages] [build/test flags & test binary flags]

go test重新编译每个包以及名称与文件模式*_test.go匹配的任何文件。这些附加文件可以包含test functions、benchmark functions和example functions。每个列出的包都会导致执行单独的测试二进制文件。文件名以_开头的文件(包括_test.go)或.被忽略

Go的test一般以xxx_ test.go为文件名

xxx的部分一般为xxx _test.go所要测试的代码文件名。

Go并未强制xxx的部分必须是要测试的文件名，只是最佳实践。

用后缀_test声明包的测试文件将被编译为单独的包，然后与主测试二进制连接并运行。go工具将会忽略名为testdata的目录，使其可以保存测试所需的辅助数据

go test的两种不同运行模式

本地目录模式，在没有包参数(例如，“go test”或“go test-v”)的情况下调用go test时发生。在此模式下，go test编译当前目录中包的源码和测试文件，然后运行生成的测试二进制文件。在此模式下，将禁用缓存。在包测试完成后，go测试打印一个显示测试状态的“摘要行”（“OK”或“FAIL”）、包名和测试的时间

包列表模式，在使用显式包参数(例如“go test math”、“go test ./…”、“go test”)调用go test时发生。在此模式下，go test编译并测试命令行中列出的每个包。如果包测试通过，则go测试只打印最终的“OK”摘要行。如果包测试失败，go test将打印完整的测试输出。如果使用-bench或-v标志调用，go测试打印完整的输出，甚至通过传递包测试，以便显示请求的基准测试结果或冗长日志记录。所有列出的包测试完成并打印输出后，如果存在任何一个包测试失败，go test将打印最终“FAIL”状态

仅在包列表模式下，go test缓存成功的包测试结果，以避免不必要的重复运行测试。当测试结果可以从缓存中恢复时，go test将重新显示以前的输出，而不是再次运行测试二进制文件。当发生这种情况时，go测试打印(缓存)代替汇总行中测试花费的时间

test文件下的每一个test case须以Test开头并且符合TestXxx形式，否则go test会直接跳过测试不执行

test case的入参为t *testing.T或b *testing.B

t.Errorf为打印错误信息，并且当前test case会被跳过

Go的test不会保证多个TestXxx是顺序执行，但是通常会按顺序执行。推荐使用 subTest

使用t.Run来执行subtests可以做到控制test输出以及test的顺序

TestMain 入口 testcase

使用TestMain作为初始化test,并且使用m.Run()来调用其他tests可

以完成一些需 要初始化操作的testing，比如数据库连接，文件打开，

REST服务登录等

如果没有在TestMain中调用m.Run()则除了TestMain以外的其他tests

都不会被执行

Test 之benchmark

• benchmark函数一般以Benchmark开头
• benchmark的case一般会跑b.N次，而且每次执行都会如此
• 在执行过程中会根据实际case的执行时间是否稳定会增加b.N的次数
  以达到稳态

运行特定的go工具

go tool [-n] command [args...]

tool运行由参数标识的go tool命令，-n标志不带参数地打印已知工具的列表

go版本信息 使用说明

go version [-m] [-v] [file ...]

go version报告用于构建每个可执行文件的go版本。如果命令行中没有命名文件，则go version将打印其自己的版本信息; 如果目录被命名，go version将遍历该目录，递归地查找识别的go二进制文件并报告它们的版本。默认情况下，go version不会报告在目录扫描期间发现的无法识别的文件

-v标志 报告无法识别的文件

-m标志 go version在可用时打印每个可执行文件的嵌入模块版本信息。在输出中，模块信息由版本行后面的多行组成，每行由一个前导制表符缩进

报告包中可能出现的错误 使用方法说明

go vet [-n] [-x] [-vettool prog] [build flags] [vet flags] [packages]

vet对由导入路径命名的包运行go vet命令

2 构建模式

====

go build和go install命令采用-buildmode参数，该参数指示要生成哪种类型的对象文件。当前支持的值为

build modes