Go是一個管理Go源代碼的工具。
用法：
go <command> [參數]
命令是：
bug 啟動錯誤報告
build 編譯包和依賴關系
clean 刪除目標文件和緩存文件
doc 顯示包或符號
env 打印文檔Go環境信息
fix 更新包以使用新API
fmt gofmt（重新格式化）包源
generate 通過源代碼生成Go文件 獲取下載並安裝包和依賴項 安裝編譯和安裝包和依賴項 列表列表包或模塊 mod模塊維護 運行編譯運行Go程序 測試測試包 工具運行指定go工具 版本打印Go版本 獸醫報告可能在包中出錯
有關命令的更多信息，請使用“go help <command>”。
其他幫助主題：
buildmode build modes c calling between Go and C cache build and test caching environment environment variables filetype file types go.mod the go.mod file gopath GOPATH environment variable gopath-get legacy GOPATH go get goproxy module proxy protocol importpath import path syntax modules modules, module versions, and more module-get module-aware go get packages package lists and patterns testflag testing flags testfunc testing functions
有關該主題的更多信息，請使用“go help <topic>”。
啟動錯誤報告
用法：
go bug
Bug打開默認瀏覽器並啟動新的錯誤報告。該報告包含有用的系統信息。
編譯包和依賴項
用法：
go build [-o output] [-i] [build flags] [packages]
Build會編譯導入路徑命名的包及其依賴項，但不會安裝結果。
如果構建的參數是.go文件的列表，則build會將它們視為指定單個包的源文件列表。
編譯單個主程序包時，build會將生成的可執行文件寫入以第一個源文件命名的輸出文件（'go build ed.go rx.go'write'ed'或'ed.exe'）或源代碼目錄（ 'go build unix / sam'寫'sam'或'sam.exe'）。編寫Windows可執行文件時會添加“.exe”后綴。
在編譯多個包或單個非主包時，build會編譯包但丟棄生成的對象，僅用於檢查是否可以構建包。
編譯包時，構建會忽略以“_test.go”結尾的文件。
-o標志僅在編譯單個包時允許，強制構建將結果可執行文件或對象寫入命名輸出文件，而不是最后兩段中描述的默認行為。
-i標志安裝作為目標依賴項的軟件包。
構建標志由構建，清理，獲取，安裝，列表，運行和測試命令共享：
-a 強制重建已經是最新的軟件包。 -n 打印命令但不運行它們。 -pn 可以並行運行 的程序數，例如構建命令或測試二進制文件。 默認值是可用的CPU數。 -race 啟用數據競爭檢測。 僅支持linux / amd64，freebsd / amd64，darwin / amd64和windows / amd64。 -msan 支持與內存清理程序的互操作。 僅支持在linux / amd64，linux / arm64上， 並且僅支持Clang / LLVM作為主機C編譯器。 -v 在編譯時打印包的名稱。 -work 打印臨時工作目錄的名稱， 退出時不要刪除它。 -x 打印命令。 -asmflags '[pattern =] arg list' 傳遞每個go工具asm調用的參數。 -buildmode mode 構建模式使用。有關更多信息，請參閱“go help buildmode”。 -compiler 要使用的編譯器名稱，如runtime.Compiler（gccgo或gc）。 -gccgoflags '[pattern =] arg list' 傳遞每個gccgo編譯器/鏈接器調用的參數。 -gcflags '[pattern =] arg list' 傳遞每個go工具編譯調用的參數。 -installsuffix suffix 在軟件包安裝目錄的名稱中使用后綴， 為了使輸出與默認構建分開。 如果使用-race標志，則安裝后綴會自動設置為race， 或者，如果明確設置，則會附加_race。同樣對於-msan 標志。使用需要非默認編譯標志的-buildmode選項 具有類似的效果。 -ldflags '[pattern =] arg list' 傳遞每個go工具鏈接調用的參數。 -linkshared 鏈接以前使用 -buildmode = shared 創建的共享庫。 -mod mode 模塊下載模式使用：readonly或vendor。 有關更多信息，請參閱“go help modules”。 -pkgdir dir 從dir 安裝並加載所有包，而不是通常的位置。 例如， 使用非標准配置構建時，請使用-pkgdir將生成的包保留在單獨的位置。 -tags '標記列表' 構建期間要考慮滿足的以空格分隔的構建標記列表。有關構建標記的更多信息，請參閱 go / build包文檔中的構建約束說明。 -toolexec 'cmd args' 用於調用vet和asm等工具鏈程序的程序。 例如，go命令不是運行asm，而是運行 'cmd args / path / to / asm <asm>的參數'。
-asmflags，-gccgoflags，-gcflags和-ldflags標志接受以空格分隔的參數列表，以在構建期間傳遞給基礎工具。要在列表中的元素中嵌入空格，請使用單引號或雙引號將其括起來。參數列表可以在包模式和等號之后，這限制了該參數列表的使用以構建匹配該模式的包（有關包模式的描述，請參閱'go help packages'）。如果沒有模式，參數列表僅適用於命令行上指定的包。可以用不同的模式重復標志，以便為不同的包組指定不同的參數。如果包與多個標志中給出的模式匹配，則命令行上的最新匹配將獲勝。例如，'go build -gcflags = -S fmt'
有關指定包的更多信息，請參閱“go help packages”。有關安裝包和二進制文件的更多信息，請運行'go help gopath'。有關在Go和C / C ++之間調用的更多信息，請運行'go help c'。
注意：Build遵守某些約定，例如'go help gopath'所描述的約定。但是，並非所有項目都遵循這些慣例。具有自己的約定或使用單獨的軟件構建系統的安裝可以選擇使用較低級別的調用，例如“go tool compile”和“go tool link”，以避免構建工具的一些開銷和設計決策。
另見：go install，go get，go clean。
刪除目標文件和緩存的文件
用法：
go clean [clean flags] [build flags] [packages]
Clean從包源目錄中刪除目標文件。go命令在臨時目錄中構建大多數對象，因此go clean主要關注其他工具留下的目標文件或go build的手動調用。
具體來說，clean從與導入路徑對應的每個源目錄中刪除以下文件：
_obj/ old object directory, left from Makefiles _test/ old test directory, left from Makefiles _testmain.go old gotest file, left from Makefiles test.out old test log, left from Makefiles build.out old test log, left from Makefiles *.[568ao] object files, left from Makefiles DIR(.exe) from go build DIR.test(.exe) from go test -c MAINFILE(.exe) from go build MAINFILE.go *.so from SWIG
在列表中，DIR表示目錄的最終路徑元素，MAINFILE是構建程序包時未包含的目錄中任何Go源文件的基本名稱。
-i標志導致clean刪除相應的已安裝存檔或二進制文件（'install install'將創建什么）。
-n標志導致clean打印它將執行的remove命令，但不運行它們。
-r標志使clean以遞歸方式應用於導入路徑命名的包的所有依賴項。
-x標志導致clean在執行它們時打印remove命令。
-cache標志導致clean刪除整個go構建緩存。
-testcache標志導致clean使go構建緩存中的所有測試結果失效。
-modcache標志導致clean刪除整個模塊下載緩存，包括版本化依賴項的解壓縮源代碼。
有關構建標志的更多信息，請參閱“go help build”。
有關指定包的更多信息，請參閱“go help packages”。
顯示包或符號的文檔
用法：
go doc [-u] [-c] [package | [package.] symbol [.methodOrField]]
Doc打印與其參數（包，const，func，類型，var，方法或結構字段）標識的項目相關聯的文檔注釋，然后是每個“下”的第一級項的一行摘要。 item（包的包級聲明，類型的方法等）。
Doc接受零個，一個或兩個參數。
沒有參數，也就是說，當運行時
go doc
它在當前目錄中打印包的包文檔。如果包是一個命令（包main），除非提供-cmd標志，否則將從表示中刪除包的導出符號。
當使用一個參數運行時，該參數被視為要記錄的項的類似Go語法的表示。參數選擇取決於GOROOT和GOPATH中安裝的內容，以及參數的形式，其中示意性之一：
go doc <pkg> go doc <sym>[.<methodOrField>] go doc [<pkg>.]<sym>[.<methodOrField>] go doc [<pkg>.][<sym>.]<methodOrField>
此參數列表中與參數匹配的第一個項目是打印其文檔的項目。（請參閱下面的示例。）但是，如果參數以大寫字母開頭，則假定它標識當前目錄中的符號或方法。
對於包，掃描的順序是以廣度優先順序詞匯確定的。也就是說，所呈現的包是與搜索匹配的包，並且最接近根並且詞法上首先在其層級的級別。在GOPATH之前，GOROOT樹總是被完整掃描。
如果沒有指定或匹配包，則選擇當前目錄中的包，因此“go doc Foo”顯示當前包中符號Foo的文檔。
包路徑必須是合格路徑或路徑的正確后綴。go工具的常用包機制不適用：包路徑元素之類的。和...不是由go doc實現的。
當使用兩個參數運行時，第一個必須是完整的包路徑（不僅僅是后綴），第二個是符號，或帶有方法或結構字段的符號。這類似於godoc接受的語法：
go doc <pkg> <sym>[.<methodOrField>]
在所有形式中，當匹配符號時，參數中的小寫字母與兩種情況匹配，但大寫字母完全匹配。這意味着如果不同的符號具有不同的情況，則包中可能存在小寫參數的多個匹配。如果發生這種情況，則打印所有匹配的文檔。
例子：
go doc Show documentation for current package. go doc Foo Show documentation for Foo in the current package. (Foo starts with a capital letter so it cannot match a package path.) go doc encoding/json Show documentation for the encoding/json package. go doc json Shorthand for encoding/json. go doc json.Number (or go doc json.number) Show documentation and method summary for json.Number. go doc json.Number.Int64 (or go doc json.number.int64) Show documentation for json.Number's Int64 method. go doc cmd/doc Show package docs for the doc command. go doc -cmd cmd/doc Show package docs and exported symbols within the doc command. go doc template.new Show documentation for html/template's New function. (html/template is lexically before text/template) go doc text/template.new # One argument Show documentation for text/template's New function. go doc text/template new # Two arguments Show documentation for text/template's New function. At least in the current tree, these invocations all print the documentation for json.Decoder's Decode method: go doc json.Decoder.Decode go doc json.decoder.decode go doc json.decode cd go/src/encoding/json; go doc decode
標志：
-all 顯示包的所有文檔。 -c 在匹配符號時尊重大小寫。 -cmd 將命令（包main）視為常規包。 否則， 在顯示程序包的頂級文檔時，將隱藏程序包主導出的符號。 -src 顯示符號的完整源代碼。這將 顯示其聲明和 定義的完整Go源，例如函數定義（包括 正文），類型聲明或封閉const 塊。因此輸出可能包括未導出的 細節。 -u 顯示未導出的 符號，方法和字段的文檔。
打印Go環境信息
用法：
go env [-json] [var ...]
Env打印Go環境信息。
默認情況下，env將信息打印為shell腳本（在Windows上，即批處理文件）。如果給出一個或多個變量名作為參數，則env在其自己的行上打印每個命名變量的值。
-json標志以JSON格式而不是shell腳本打印環境。
有關環境變量的更多信息，請參閱“go help environment”。
更新包以使用新API
用法：
go fix [packages]
Fix在導入路徑命名的包上運行Go fix命令。
有關修復的更多信息，請參閱“go doc cmd / fix”。有關指定包的更多信息，請參閱“go help packages”。
要使用特定選項運行修復，請運行“go tool fix”。
另見：go fmt，go vet。
Gofmt（重新格式化）包源
用法：
go fmt [-n] [-x] [packages]
Fmt在導入路徑命名的包上運行命令'gofmt -l -w'。它打印修改的文件的名稱。
有關gofmt的更多信息，請參閱“go doc cmd / gofmt”。有關指定包的更多信息，請參閱“go help packages”。
-n標志打印將要執行的命令。-x標志在執行時打印命令。
要使用特定選項運行gofmt，請運行gofmt本身。
另見：go fix，go vet。
通過處理源生成Go文件
用法：
go generate [-run regexp] [-n] [-v] [-x] [build flags] [file.go ... | 包]
生成由現有文件中的指令描述的運行命令。這些命令可以運行任何進程，但目的是創建或更新Go源文件。
Go generate永遠不會通過go build，go get，go test等自動運行。它必須明確運行。
Go生成掃描文件中的指令，這些指令是表單的行，
// go：生成命令參數...
（注意：“// go”中沒有前導空格和空格）其中command是要運行的生成器，對應於可以在本地運行的可執行文件。它必須位於shell路徑（gofmt），完全限定的路徑（/ usr / you / bin / mytool）或命令別名中，如下所述。
為了向人類和機器工具傳達生成代碼，生成的源應該具有與以下正則表達式匹配的行（在Go語法中）：
^ //生成代碼。*不要編輯\。$
該行可能出現在文件的任何位置，但通常位於開頭附近，因此很容易找到。
請注意，go generate不會解析文件，因此看起來像注釋或多行字符串中的指令的行將被視為指令。
該指令的參數是空格分隔的標記或雙引號字符串，它們在運行時作為單獨的參數傳遞給生成器。
帶引號的字符串使用Go語法並在執行之前進行評估; 帶引號的字符串作為生成器的單個參數出現。
Go運行生成器時生成幾個變量：
$GOARCH 執行架構（arm，amd64等） $GOOS 執行操作系統（linux，windows等） $GOFILE 文件的基本名稱。 $GOLINE 源文件中指令的行號。 $GOPACKAGE 包含指令的文件包的名稱。 $DOLLAR 美元符號。
除了變量替換和引用字符串評估之外，在命令行上不執行諸如“globbing”之類的特殊處理。
作為運行命令之前的最后一步，任何具有字母數字名稱的環境變量（例如$ GOFILE或$ HOME）的調用都將在整個命令行中進行擴展。變量擴展的語法是所有操作系統上的$ NAME。由於評估的順序，變量甚至在引用的字符串內擴展。如果未設置變量NAME，則$ NAME將擴展為空字符串。
表格的指示，
// go：generate -command xxx args ...
僅為此源文件的剩余部分指定字符串xxx表示由參數標識的命令。這可用於創建別名或處理多字生成器。例如，
// go：generate -command foo go tool foo
指定命令“foo”表示生成器“go tool foo”。
按命令行上給出的順序生成進程包，一次一個。如果命令行列出.go文件，則將它們視為單個包。在包中，按文件名順序生成處理包中的源文件，一次一個。在源文件中，按照它們在文件中出現的順序生成運行生成器，一次一個。
如果任何生成器返回錯誤退出狀態，“go generate”將跳過該包的所有進一步處理。
生成器在包的源目錄中運行。
Go generate接受一個特定的標志：
-run="" 如果非空，則指定正則表達式以選擇 其完整原始源文本（不包括 任何尾隨空格和最終換行符）與 表達式匹配的指令。
它還接受標准構建標志，包括-v，-n和-x。-v標志在處理包時打印包和文件的名稱。-n標志打印將要執行的命令。-x標志在執行時打印命令。
有關構建標志的更多信息，請參閱“go help build”。
有關指定包的更多信息，請參閱“go help packages”。
下載並安裝包和依賴項
用法：
go get [-d] [-f] [-t] [-u] [-v] [-fix] [-insecure] [build flags] [packages]
獲取導入路徑指定的包及其依賴項的下載。然后安裝命名包，比如'go install'。
-d標志指示在下載軟件包后停止; 也就是說，它指示不安裝軟件包。
-f標志僅在設置-u時有效，強制get -u不驗證每個包是否已從其導入路徑隱含的源控制存儲庫中檢出。如果源是原始的本地分支，這可能很有用。
-fix標志指示get在解析依賴項或構建代碼之前在下載的包上運行修復工具。
-insecure標志允許從存儲庫中提取並使用不安全的方案（如HTTP）解析自定義域。謹慎使用。
-t標志指示get還下載構建指定包的測試所需的包。
-u標志指示get使用網絡更新命名包及其依賴項。默認情況下，get使用網絡檢出丟失的包，但不使用它來查找現有包的更新。
-v標志啟用詳細進度和調試輸出。
Get還接受構建標志來控制安裝。請參閱'go help build'。
簽出新包時，get創建目標目錄GOPATH / src / <import-path>。如果GOPATH包含多個條目，則get使用第一個條目。有關詳細信息，請參閱：'go help gopath'。
簽出或更新包時，查找與本地安裝的Go版本匹配的分支或標記。最重要的規則是，如果本地安裝運行版本為“go1”，則搜索名為“go1”的分支或標記。如果不存在此類版本，則會檢索包的默認分支。
當獲取簽出或更新Git存儲庫時，它還會更新存儲庫引用的任何git子模塊。
永遠不會檢出或更新存儲在供應商目錄中的代碼。
有關指定包的更多信息，請參閱“go help packages”。
有關“go get”如何找到要下載的源代碼的更多信息，請參閱“go help importpath”。
本文描述了使用GOPATH管理源代碼和依賴項時get的行為。如果go命令在模塊感知模式下運行，則get的標志和效果的細節會發生變化，就像'go help get'一樣。請參閱“go help modules”和“go help module-get”。
另見：go build，go install，go clean。
編譯並安裝包和依賴項
用法：
go install [-i] [build flags] [packages]
安裝編譯並安裝導入路徑命名的包。
-i標志也會安裝命名包的依賴項。
有關構建標志的更多信息，請參閱“go help build”。有關指定包的更多信息，請參閱“go help packages”。
另見：go build，go get，go clean。
列出包或模塊
用法：
go list [-f format] [-json] [-m] [list flags] [build flags] [packages]
列表列出了命名包，每行一個。最常用的標志是-f和-json，它們控制為每個包打印的輸出形式。下面記錄的其他列表標志控制更具體的細節。
默認輸出顯示包導入路徑：
bytes encoding/json github.com/gorilla/mux golang.org/x/net/html
-f標志使用包模板的語法指定列表的備用格式。默認輸出等效於-f'{{。ImmortPath}}'。傳遞給模板的結構是：
type Package struct { Dir string // directory containing package sources ImportPath string // import path of package in dir ImportComment string // path in import comment on package statement Name string // package name Doc string // package documentation string Target string // install path Shlib string // the shared library that contains this package (only set when -linkshared) Goroot bool // is this package in the Go root? Standard bool // is this package part of the standard Go library? Stale bool // would 'go install' do anything for this package? StaleReason string // explanation for Stale==true Root string // Go root or Go path dir containing this package ConflictDir string // this directory shadows Dir in $GOPATH BinaryOnly bool // binary-only package: cannot be recompiled from sources 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 }
存儲在供應商目錄中的包報告ImportPath，其中包含供應商目錄的路徑（例如，“d / vendor / p”而不是“p”），以便ImportPath唯一地標識包的給定副本。Imports，Deps，TestImports和XTestImports列表還包含這些擴展的導入路徑。有關vendoring的更多信息，請參閱golang.org/s/go15vendor。
錯誤信息（如果有）是
type PackageError struct { ImportStack []string // shortest path from package named on command line to this one Pos string // position of error (if present, file:line:col) Err string // the error itself }
模塊信息是Module結構，在下面列表-m的討論中定義。
模板函數“join”調用strings.Join。
模板函數“context”返回構建上下文，定義如下：
type Context struct { GOARCH string // target architecture GOOS string // target operating system GOROOT string // Go root GOPATH string // Go path CgoEnabled bool // whether cgo can be used UseAllFiles bool // use files regardless of +build lines, file names Compiler string // compiler to assume when computing target paths BuildTags []string // build constraints to match in +build lines ReleaseTags []string // releases the current release is compatible with InstallSuffix string // suffix to use in the name of the install dir }
有關這些字段含義的更多信息，請參閱go / build包的Context類型的文檔。
-json標志使包數據以JSON格式打印，而不是使用模板格式。
-compiled標志導致list將CompiledGoFiles設置為呈現給編譯器的Go源文件。通常，這意味着它會重復GoFiles中列出的文件，然后還會添加通過處理CgoFiles和SwigFiles生成的Go代碼。Imports列表包含來自GoFiles和CompiledGoFiles的所有導入的並集。
-deps標志使列表不僅迭代命名包而且迭代所有依賴關系。它在深度優先的后序遍歷中訪問它們，以便僅在所有依賴項之后列出包。未在命令行中明確列出的包將DepOnly字段設置為true。
-e標志更改錯誤包的處理，無法找到或錯誤的包。默認情況下，list命令會為每個錯誤的包打印一個錯誤標准錯誤，並在通常的打印過程中省略所考慮的包。使用-e標志，list命令永遠不會將錯誤打印到標准錯誤，而是使用通常的打印處理錯誤的包。錯誤的包將具有非空的ImportPath和非零錯誤字段; 其他信息可能會或可能不會丟失（歸零）。
-export標志使列表將Export字段設置為包含給定包的最新導出信息的文件的名稱。
-find標志使列表標識命名包但不解析它們的依賴關系：Imports和Deps列表將為空。
-test標志使列表不僅報告命名包而且報告測試二進制文件（對於帶有測試的包），以准確地向源代碼分析工具傳達測試二進制文件的構造方式。報告的測試二進制文件的導入路徑是包的導入路徑，后跟“.test”后綴，如“math / rand.test”。在構建測試時，有時需要專門為該測試重建某些依賴項（最常見的是測試包本身）。報告的針對特定測試二進制文件重新編譯的包的導入路徑后跟一個空格和括號中的測試二進制文件的名稱，如“math / rand [math / rand.test]”或“regexp [sort.test] ”。ForTest字段也設置為正在測試的包的名稱（“math / rand”或“sort”
Dir，Target，Shlib，Root，ConflictDir和Export文件路徑都是絕對路徑。
默認情況下，列表GoFiles，CgoFiles等保存Dir中的文件名（即相對於Dir的路徑，而不是絕對路徑）。使用-compiled和-test標志時添加的生成文件是引用生成的Go源文件的緩存副本的絕對路徑。雖然它們是Go源文件，但路徑可能不會以“.go”結尾。
-m標志使列表列出模塊而不是包。
列出模塊時，-f標志仍指定應用於Go結構的格式模板，但現在是Module結構：
type Module struct { Path string // module path Version string // module version Versions []string // available module versions (with -versions) Replace *Module // replaced by this module Time *time.Time // time version was created Update *Module // available update, if any (with -u) Main bool // is this the main module? Indirect bool // is this module only an indirect dependency of main module? Dir string // directory holding files for this module, if any GoMod string // path to go.mod file for this module, if any Error *ModuleError // error loading module } type ModuleError struct { Err string // the error itself }
默認輸出是打印模塊路徑，然后打印有關版本和替換的信息（如果有）。例如，'go list -m all'可能會打印：
my / main / module golang.org/x/text v0.3.0 => / tmp / text rsc.io/pdf v0.1.1
Module結構有一個String方法，用於格式化這一行輸出，因此默認格式等同於-f'{{。String}}'。
請注意，更換模塊后，其“替換”字段描述替換模塊，其“目錄”字段設置為替換的源代碼（如果存在）。（也就是說，如果Replace為非nil，則Dir設置為Replace.Dir，無法訪問替換的源代碼。）
-u標志添加有關可用升級的信息。當給定模塊的最新版本比當前模塊更新時，列表-u將Module的Update字段設置為有關較新模塊的信息。Module的String方法通過在當前版本之后格式化括號中的較新版本來指示可用的升級。例如，'go list -m -u all'可能會打印：
my / main / module golang.org/x/text v0.3.0 [v0.4.0] => / tmp / text rsc.io/pdf v0.1.1 [v0.1.2]
（對於工具，'go list -m -u -json all'可能更方便解析。）
-versions標志導致list將Module的Versions字段設置為該模塊的所有已知版本的列表，按照語義版本排序，最早到最新。該標志還更改默認輸出格式以顯示模塊路徑，后跟空格分隔的版本列表。
list -m的參數被解釋為模塊列表，而不是包。主模塊是包含當前目錄的模塊。活動模塊是主模塊及其依賴項。沒有參數，list -m顯示主模塊。使用參數，list -m顯示參數指定的模塊。任何活動模塊都可以通過其模塊路徑指定。特殊模式“all”指定所有活動模塊，首先是主模塊，然后是依賴於模塊路徑的依賴項。包含“...”的模式指定模塊路徑與模式匹配的活動模塊。表單路徑@ version的查詢指定該查詢的結果，該查詢不限於活動模塊。有關模塊查詢的更多信息，請參閱“go help modules”。
模板函數“module”采用單個字符串參數，該參數必須是模塊路徑或查詢，並將指定的模塊作為Module結構返回。如果發生錯誤，結果將是具有非零錯誤字段的Module結構。
有關構建標志的更多信息，請參閱“go help build”。
有關指定包的更多信息，請參閱“go help packages”。
有關模塊的更多信息，請參閱“go help modules”。
模塊維護
Go mod提供對模塊操作的訪問。
請注意，對所有go命令都內置了對模塊的支持，而不僅僅是'go mod'。例如，應使用“go get”來完成依賴項的日常添加，刪除，升級和降級。有關模塊功能的概述，請參閱“go help modules”。
用法：
go mod <command> [arguments]
命令是：
download download modules to local cache edit edit go.mod from tools or scripts graph print module requirement graph init initialize new module in current directory tidy add missing and remove unused modules vendor make vendored copy of dependencies verify verify dependencies have expected content why explain why packages or modules are needed
有關命令的更多信息，請使用“go help mod <command>”。
將模塊下載到本地緩存
用法：
go mod download [-json] [modules]
下載下載命名模塊，可以是模塊模式選擇主模塊的依賴關系或模板路徑@版本的模塊查詢。沒有參數，下載適用於主模塊的所有依賴項。
go命令將在普通執行期間根據需要自動下載模塊。“go mod download”命令主要用於預填充本地緩存或計算Go模塊代理的答案。
默認情況下，下載會將錯誤報告為標准錯誤，否則將保持靜默。-json標志導致下載將一系列JSON對象打印到標准輸出，描述每個下載的模塊（或失敗），對應於此Go結構：
type Module struct { Path string // module path Version string // module version Error string // error loading module Info string // absolute path to cached .info file GoMod string // absolute path to cached .mod file Zip string // absolute path to cached .zip file Dir string // absolute path to cached source root directory Sum string // checksum for path, version (as in go.sum) GoModSum string // checksum for go.mod (as in go.sum) }
有關模塊查詢的更多信息，請參閱“go help modules”。
從工具或腳本編輯go.mod
用法：
go mod edit [editing flags] [go.mod]
Edit提供了一個命令行界面，用於編輯go.mod，主要用於工具或腳本。它只讀取go.mod; 它沒有查找有關模塊的信息。默認情況下，編輯讀取和寫入主模塊的go.mod文件，但可以在編輯標志之后指定不同的目標文件。
編輯標志指定一系列編輯操作。
-fmt標志重新格式化go.mod文件而不進行其他更改。使用或重寫go.mod文件的任何其他修改也暗示了這種重新格式化。唯一需要此標志的是如果沒有指定其他標志，如'go mod edit -fmt'。
-module標志更改模塊的路徑（go.mod文件的模塊行）。
-require = path @ version和-droprequire = path標志在給定的模塊路徑和版本上添加和刪除需求。請注意，-require會覆蓋路徑上的所有現有要求。這些標志主要用於了解模塊圖的工具。用戶應該更喜歡“go get path @ version”或“go get path @ none”，這樣可以根據需要進行其他go.mod調整，以滿足其他模塊施加的限制。
-exclude = path @ version和-dropexclude = path @ version flags為給定的模塊路徑和版本添加和刪除排除項。請注意，如果排除已存在，則--exclude = path @ version是無操作。
-replace = old [@v] = new [@v]和-dropreplace = old [@v]標志添加和刪除給定模塊路徑和版本對的替換。如果省略舊@v中的@v，則替換適用於具有舊模塊路徑的所有版本。如果省略new @ v中的@v，則新路徑應該是本地模塊根目錄，而不是模塊路徑。請注意，-replace會覆蓋舊[@v]的任何現有替換。
可以重復-require，-droprequire，-exclude，-dropexclude，-replace和-dropreplace編輯標志，並且按照給定的順序應用更改。
-go = version標志設置預期的Go語言版本。
-print標志以文本格式打印最終的go.mod，而不是將其寫回go.mod。
-json標志以JSON格式打印最終的go.mod文件，而不是將其寫回go.mod。JSON輸出對應於這些Go類型：
type Module struct { Path string Version string } type GoMod struct { Module Module Go string Require []Require Exclude []Module Replace []Replace } type Require struct { Path string Version string Indirect bool } type Replace struct { Old Module New Module }
請注意，這僅描述了go.mod文件本身，而不是間接引用的其他模塊。對於構建可用的完整模塊集，請使用'go list -m -json all'。
例如，工具可以通過解析'go mod edit -json'的輸出來獲取go.mod作為數據結構，然后可以通過使用-require，-exclude等調用'go mod edit'來進行更改。
打印模塊依賴關系圖
用法：
go mod graph
圖形以文本形式打印模塊需求圖（應用了替換）。輸出中的每一行都有兩個以空格分隔的字段：一個模塊和一個要求。每個模塊都被標識為表單路徑@版本的字符串，但主模塊除外，它沒有@version后綴。
在當前目錄中初始化新模塊
用法：
go mod init [module]
Init初始化並將新的go.mod寫入當前目錄，實際上創建了一個以當前目錄為根的新模塊。文件go.mod必須不存在。如果可能，init將從導入注釋（請參閱“go help importpath”）或版本控制配置中猜測模塊路徑。要覆蓋此猜測，請將模塊路徑作為參數提供。
添加缺失並刪除未使用的模塊
用法：
go mod tidy [-v]
Tidy確保go.mod匹配模塊中的源代碼。它添加了構建當前模塊的包和依賴項所需的任何缺少的模塊，並刪除了未提供任何相關包的未使用模塊。它還將任何缺少的條目添加到go.sum並刪除任何不必要的條目。
-v標志導致整理將有關已刪除模塊的信息打印到標准錯誤。
制作依賴項的vendor副本
用法：
go mod vendor [-v]
供應商重置主模塊的供應商目錄，以包括構建和測試所有主模塊包所需的所有包。它不包括銷售包裹的測試代碼。
-v標志使供應商將出售模塊和包的名稱打印為標准錯誤。
驗證依賴項是否具有預期內容
用法：
go mod verify
驗證檢查當前模塊的依賴關系（存儲在本地下載的源緩存中）自下載以來未被修改。如果所有模塊都未修改，請驗證打印“所有模塊已驗證”。否則，它會報告哪些模塊已被更改，並導致'go mod'以非零狀態退出。
解釋為什么需要包或模塊
用法：
go mod why [-m] [-vendor] packages...
為什么在導入圖中顯示從主模塊到每個列出的包的最短路徑。如果給出-m標志，為什么將參數視為模塊列表並找到每個模塊中任何包的路徑。
默認情況下，為什么查詢與“go list all”匹配的包的圖形，其中包括對可訪問包的測試。-vendor標志導致為什么要排除依賴項的測試。
輸出是一系列節，一個用於命令行上的每個包或模塊名稱，用空行分隔。每個節都以注釋行“#package”或“＃module”開頭，給出目標包或模塊。后續行給出了導入圖的路徑，每行一個包。如果未從主模塊引用包或模塊，則該節將顯示指示該事實的單個帶括號的注釋。
例如：
$ go mod why golang.org/x/text/language golang.org/x/text/encoding # golang.org/x/text/language rsc.io/quote rsc.io/sampler golang.org/x/text/language # golang.org/x/text/encoding (main module does not need package golang.org/x/text/encoding) $
編譯並運行Go程序
用法：
go run [build flags] [-exec xprog] package [arguments ...]
運行編譯並運行命名的主Go包。通常，包被指定為.go源文件的列表，但它也可以是與單個已知包匹配的導入路徑，文件系統路徑或模式，如“go run”。或'去運行我的/ cmd'。
默認情況下，'go run'直接運行已編譯的二進制文件：'a.out arguments ...'。如果給出-exec標志，'go run'使用xprog調用二進制文件：
'xprog a.out arguments...'.
如果未給出-exec標志，則GOOS或GOARCH與系統默認值不同，並且可以在當前搜索路徑上找到名為go_ $ GOOS_ $ GOARCH_exec的程序，“go run”使用該程序調用二進制文件，例如'go_nacl_386_exec a.out arguments ...'。這允許在模擬器或其他執行方法可用時執行交叉編譯的程序。
Run的退出狀態不是已編譯二進制文件的退出狀態。
有關構建標志的更多信息，請參閱“go help build”。有關指定包的更多信息，請參閱“go help packages”。
另見：go build。
測試包
用法：
go test [build / test flags] [packages] [build / test flags＆test binary flags]
“Go test”自動測試導入路徑命名的包。它以以下格式打印測試結果的摘要：
ok archive / tar 0.011s FAIL archive / zip 0.022s ok compress / gzip 0.033s ...
然后是每個失敗包的詳細輸出。
“Go test”重新編譯每個包以及名稱與文件模式“* _test.go”匹配的任何文件。這些附加文件可以包含測試函數，基准函數和示例函數。有關更多信息，請參閱“go help testfunc”。每個列出的包都會導致執行單獨的測試二進制文件。名稱以“_”或"."開頭的文件（包括“_test.go”） 被忽略了。
聲明具有后綴“_test”的包的測試文件將被編譯為單獨的包，然后鏈接並與主測試二進制文件一起運行。
go工具將忽略名為“testdata”的目錄，使其可用於保存測試所需的輔助數據。
作為構建測試二進制文件的一部分，測試運行對包及其測試源文件進行檢查以識別重大問題。如果發現任何問題，請去測試報告那些並且不運行測試二進制文件。僅使用默認go vet檢查的高可信子集。該子集是：'atomic'，'bool'，'buildtags'，'nilfunc'和'printf'。您可以通過“go doc cmd / vet”查看這些和其他獸醫測試的文檔。要禁用go vet的運行，請使用-vet = off標志。
所有測試輸出和匯總行都打印到go命令的標准輸出，即使測試將它們打印到自己的標准錯誤。（go命令的標准錯誤保留用於構建測試的打印錯誤。）
Go測試以兩種不同的模式運行：
第一種稱為本地目錄模式，在沒有包參數的情況下調用go test時發生（例如，'go test'或'go test -v'）。在此模式下，go test將編譯當前目錄中的包源和測試，然后運行生成的測試二進制文件。在此模式下，禁用緩存（下面討論）。包測試完成后，go test打印一條摘要行，顯示測試狀態（'ok'或'FAIL'），包名稱和已用時間。
第二種叫做包列表模式，在使用顯式包參數調用go test時發生（例如'go test math'，'go test。/ ...'，甚至'go test。'）。在此模式下，go test編譯並測試命令行中列出的每個包。如果包測試通過，則go test僅打印最終的'ok'摘要行。如果包測試失敗，則go test打印完整的測試輸出。如果使用-bench或-v標志調用，則即使傳遞包測試，go test也會打印完整輸出，以顯示請求的基准測試結果或詳細日志記錄。
僅在包列表模式下，go test緩存成功的包測試結果，以避免不必要的重復運行測試。當可以從緩存中恢復測試結果時，go test將重新顯示先前的輸出，而不是再次運行測試二進制。發生這種情況時，請在測試打印'（緩存）'代替摘要行中的已用時間。
緩存中匹配的規則是運行涉及相同的測試二進制文件，命令行上的標志完全來自一組受限制的“可緩存”測試標志，定義為-cpu，-list，-parallel，-run ，-short和-v。如果運行go測試在此集合之外有任何測試或非測試標志，則不會緩存結果。要禁用測試緩存，請使用除可緩存標志之外的任何測試標志或參數。顯式禁用測試緩存的慣用方法是使用-count = 1。在包的源根目錄（通常是$ GOPATH）中打開文件或參考環境變量的測試僅匹配文件和環境變量未更改的未來運行。緩存的測試結果在任何時候都被視為執行，因此無論-timeout設置如何，都將緩存並重用成功的包測試結果。
In addition to the build flags, the flags handled by 'go test' itself are:
-args 將命令行的其余部分（-args之后的所有內容） 傳遞給測試二進制文件，取消解釋並保持不變。 由於此標志占用命令行的其余部分， 因此包列表（如果存在）必須出現在此標志之前。 -c 將測試二進制文件編譯為pkg.test但不運行它 （其中pkg是包的導入路徑的最后一個元素）。 可以使用-o標志更改文件名。 -exec xprog 使用xprog運行測試二進制文件。行為與 'go run'中的行為相同。有關詳細信息，請參閱“go help run”。 -i 安裝作為測試依賴項的包。 不要運行測試。 -json 將測試輸出轉換為適合自動處理的JSON。 有關編碼詳細信息，請參閱“go doc test2json”。 -o file 將測試二進制文件編譯為指定文件。 測試仍然運行（除非指定了-c或-i）。
測試二進制文件還接受控制測試執行的標志; 這些標志也可以通過'go test'訪問。有關詳細信息，請參閱“go help testflag”。
有關構建標志的更多信息，請參閱“go help build”。有關指定包的更多信息，請參閱“go help packages”。
另見：go build，go vet。
運行指定的go工具
用法：
go tool [-n] command [args...]
Tool運行由參數標識的go工具命令。沒有參數，它打印已知工具列表。
-n標志使工具打印將要執行但不執行它的命令。
有關每個工具命令的更多信息，請參閱“go doc cmd / <command>”。
打印Go版本
用法：
go version
版本打印Go版本，由runtime.Version報告。
檢查包中可能出現的錯誤
用法：
go vet [-n] [-x] [-vettool prog] [build flags] [vet flags] [packages]
Vet在導入路徑命名的包上運行Go vet命令。
有關獸醫及其旗幟的更多信息，請參閱“go doc cmd / vet”。有關指定包的更多信息，請參閱“go help packages”。有關檢查器及其標志的列表，請參閱“go tool vet help”。有關特定檢查器（如“printf”）的詳細信息，請參閱“go tool vet help printf”。
-n標志打印將要執行的命令。-x標志在執行時打印命令。
-vettool = prog標志選擇具有替代或附加檢查的不同分析工具。例如，可以使用以下命令構建和運行'shadow'分析器：
go install golang.org/x/tools/go/analysis/passes/shadow/cmd/shadow go vet -vettool = $（which shadow）
go vet支持的構建標志是控制包解析和執行的構建標志，例如-n，-x，-v，-tags和-toolexec。有關這些標志的更多信息，請參閱“go help build”。
另見：go fmt，go fix。
構建模式
'go build'和'go install'命令采用-buildmode參數，該參數指示要構建哪種對象文件。目前支持的值是：
-buildmode = archive 將列出的非主包構建到.a文件中。名為 main的包將被忽略。 -buildmode = c-archive 將列出的主程序包及其導入的所有程序包構建 到C歸檔文件中。唯一可調用的符號將是 使用cgo // export注釋導出的函數。只需要 列出一個主要包。 -buildmode = c-shared 將列出的主程序包及其導入的所有程序包構建 到C共享庫中。唯一可調用的符號將 是使用cgo // export注釋導出的函數。 只需要列出一個主要包。 -buildmode = default 列出的主程序包內置於可執行文件中，列出的 非主程序包內置於.a文件中（默認 行為）。 -buildmode = shared 所有列出的非主包合並到一個共享 庫中，該庫將在使用-linkshared 選項構建時使用。名為main的包將被忽略。 -buildmode = exe 構建列出的主包及其導入 可執行文件的所有內容。未命名為main的包將被忽略。 -buildmode = pie 構建列出的主包及其導入的 位置獨立可執行文件（PIE）。未命名為 main的包將被忽略。 -buildmode = plugin 將列出的主要包以及它們 導入的所有包構建到Go插件中。未命名為main的包將被忽略。
在Go和C之間調用
在Go和C / C ++代碼之間調用有兩種不同的方法。
第一個是cgo工具，它是Go發行版的一部分。有關如何使用它的信息，請參閱cgo文檔（go doc cmd / cgo）。
第二個是SWIG程序，它是語言之間接口的通用工具。有關SWIG的信息，請參閱 http://swig.org/。運行go build時，任何擴展名為.swig的文件都將傳遞給SWIG。任何擴展名為.swigcxx的文件都將使用-c ++選項傳遞給SWIG。
當使用cgo或SWIG時，go build會將任何.c，.m，.s或.S文件傳遞給C編譯器，將任何.cc，.cpp，.cxx文件傳遞給C ++編譯器。可以設置CC或CXX環境變量以分別確定要使用的C或C ++編譯器。
構建和測試緩存
go命令緩存構建輸出以便在將來的構建中重用。緩存數據的默認位置是當前操作系統的標准用戶緩存目錄中名為go-build的子目錄。設置GOCACHE環境變量會覆蓋此默認值，並且運行“go env GOCACHE”將打印當前緩存目錄。
go命令定期刪除最近未使用的緩存數據。運行'go clean -cache'會刪除所有緩存的數據。
構建緩存正確地考慮了對Go源文件，編譯器，編譯器選項等的更改：在典型使用中不應該明確清除緩存。但是，構建緩存不會檢測使用cgo導入的C庫的更改。如果您對系統上的C庫進行了更改，則需要顯式清理緩存，或者使用-a build標志（請參閱“go help build”）強制重建依賴於更新的C庫的包。
go命令還可以緩存成功的包測試結果。有關詳細信息，請參閱“go help test”。運行'go clean -testcache'會刪除所有緩存的測試結果（但不會緩存構建結果）。
GODEBUG環境變量可以打印有關緩存狀態的調試信息：
GODEBUG = gocacheverify = 1導致go命令繞過任何緩存條目的使用，而是重建所有內容並檢查結果是否與現有緩存條目匹配。
GODEBUG = gocachehash = 1導致go命令打印用於構造緩存查找鍵的所有內容哈希的輸入。輸出很大，但可用於調試緩存。
GODEBUG = gocachetest = 1導致go命令打印關於是否重用緩存的測試結果的決定的詳細信息。
環境變量
go命令及其調用的工具檢查幾個不同的環境變量。對於其中許多，您可以通過運行'go env NAME'來查看系統的默認值，其中NAME是變量的名稱。
通用環境變量：
GCCGO 運行'go build -compiler = gccgo'的gccgo命令。 GOARCH 用於編譯代碼的體系結構或處理器。 例子是amd64,386，arm，ppc64。 GOBIN'go install'將安裝命令的目錄。 GOCACHE go命令將存儲緩存 信息的目錄，以便在將來的構建中重用。 GOFLAGS 當 當前命令知道給定標志時，默認情況下 應用於go命令的空格分隔的-flag = value設置列表。命令行 中列出的標志將在此列表后應用，因此會覆蓋它。 GOOS 編譯代碼的操作系統。 例如linux，darwin，windows，netbsd。 GOPATH 欲了解更多詳情，請參閱：'go help gopath'。 Go模塊代理的 GOPROXY URL。請參閱'go help goproxy'。 GORACE 競賽探測器的選項。 請參閱https://golang.org/doc/articles/race_detector.html。 GOROOT go樹的根。 GOTMPDIR go命令將寫入 臨時源文件，包和二進制文件的目錄。
GOFLAGS列表中的每個條目都必須是獨立標志。由於條目是以空格分隔的，因此標志值不得包含空格。
與cgo一起使用的環境變量：
CC 用於編譯C代碼的命令。 CGO_ENABLED 是否支持cgo命令。0或1. CGO_CFLAGS 在編譯 C代碼時cgo將傳遞給編譯器的標志。 CGO_CFLAGS_ALLOW 一個正則表達式，指定允許 出現在#cgo CFLAGS源代碼指令中的其他標志。 不適用於CGO_CFLAGS環境變量。 CGO_CFLAGS_DISALLOW 一個正則表達式，指定必須禁止 出現在#cgo CFLAGS源代碼指令中的標志。 不適用於CGO_CFLAGS環境變量。 CGO_CPPFLAGS，CGO_CPPFLAGS_ALLOW，CGO_CPPFLAGS_DISALLOW 像CGO_CFLAGS，CGO_CFLAGS_ALLOW和CGO_CFLAGS_DISALLOW， 但是對於C預處理器。 CGO_CXXFLAGS，CGO_CXXFLAGS_ALLOW，CGO_CXXFLAGS_DISALLOW 與CGO_CFLAGS，CGO_CFLAGS_ALLOW和CGO_CFLAGS_DISALLOW類似， 但是對於C ++編譯器。 CGO_FFLAGS，CGO_FFLAGS_ALLOW，CGO_FFLAGS_DISALLOW 與CGO_CFLAGS，CGO_CFLAGS_ALLOW和CGO_CFLAGS_DISALLOW類似， 但對於Fortran編譯器。 CGO_LDFLAGS，CGO_LDFLAGS_ALLOW，CGO_LDFLAGS_DISALLOW 與CGO_CFLAGS，CGO_CFLAGS_ALLOW和CGO_CFLAGS_DISALLOW類似， 但是對於鏈接器。 CXX 用於編譯C ++代碼的命令。 PKG_CONFIG pkg-config工具的路徑。 AR 使用 gccgo編譯器構建時用於操作庫歸檔的命令。 默認為'ar'。
體系結構特定的環境變量：
GOARM 對於GOARCH = arm，要編譯的ARM體系結構。 有效值為 5,6,7。GO386 對於GOARCH = 386，浮點指令集。 有效值為387，sse2。 GOMIPS 對於GOARCH = mips {，le}，是否使用浮點指令。 有效值為hardfloat（默認），softfloat。 GOMIPS64 對於GOARCH = mips64 {，le}，是否使用浮點指令。 有效值為hardfloat（默認），softfloat。
專用環境變量：
GCCGOTOOLDIR 如果設置，在哪里可以找到gccgo工具，例如cgo。 默認值基於gccgo的配置方式。 GOROOT_FINAL 安裝的Go樹的根目錄，當它 安裝在構建它以外的位置時。 堆棧跟蹤中的文件名從GOROOT重寫為 GOROOT_FINAL。 GO_EXTLINK_ENABLED 使用-linkmode = auto時 ，鏈接器是否應使用外部鏈接模式，代碼使用cgo。 設置為0表示禁用外部鏈接模式，設置為1表示啟用它。 GIT_ALLOW_PROTOCOL 由Git定義。以冒號分隔的方案列表，允許 與git fetch / clone一起使用。如果設置，任何未明確提及的方案都將是 被'去得'認為不安全。
“go env”提供的其他信息，但未從環境中讀取：
GOEXE 可執行文件名后綴（Windows上為“.exe”，其他系統上為“”）。 GOHOSTARCH Go工具鏈二進制文件的體系結構（GOARCH）。 GOHOSTOS Go工具鏈二進制文件的操作系統（GOOS）。 GOMOD 主模塊的go.mod 的絕對路徑， 如果不使用模塊則為空字符串。 GOTOOLDIR 安裝go工具（編譯，封面，doc等）的目錄。
文件類型
go命令檢查每個目錄中受限文件集的內容。它根據文件名的擴展名標識要檢查的文件。這些擴展是：
.go Go源文件。 .c，.h C源文件。 如果軟件包使用cgo或SWIG，這些將使用 OS本機編譯器（通常是gcc）進行編譯; 否則會 觸發錯誤。 .cc，.cpp，.cxx，.hh，.hpp，.hxx C ++源文件。僅適用於cgo或SWIG，並且始終 使用OS本機編譯器進行編譯。 .m Objective-C源文件。僅適用於cgo，並始終 使用OS本機編譯器進行編譯。 .s，.S 匯編源文件。 如果軟件包使用cgo或SWIG，它們將與 OS本機匯編程序（通常是gcc（sic））組裝在一起; 否則他們 將與Go匯編程序組裝在一起。 .swig，.swigcxx SWIG定義文件。 .syso 系統對象文件。
除.syso之外的每個類型的文件都可能包含構建約束，但是go命令會停止掃描文件中第一個不是空行或//樣式行注釋的構建約束。有關更多詳細信息，請參閱go / build包文檔。
通過Go 1.12版本，非測試Go源文件還可以包含// go：binary-only-package注釋，指示包源僅包含在文檔中，不得用於構建包二進制文件。這樣就可以單獨以編譯形式分發Go包。即使是僅二進制包也需要准確的導入塊來列出所需的依賴關系，以便在鏈接生成的命令時可以提供這些依賴關系。請注意，此功能計划在Go 1.12發布后刪除。
go.mod文件
模塊版本由源文件樹定義，其根目錄中包含go.mod文件。當運行go命令時，它會查找當前目錄，然后查找連續的父目錄，以查找標記主（當前）模塊根目錄的go.mod。
go.mod文件本身是面向行的，帶有//注釋但沒有/ * * / comments。每行包含一個指令，由一個動詞后跟參數組成。例如：
module my/thing go 1.12 require other/thing v1.0.2 require new/thing/v2 v2.3.4 exclude old/thing v1.2.3 replace bad/thing v1.4.5 => good/thing v1.4.5
動詞是
module, to define the module path; go, to set the expected language version; require, to require a particular module at a given version or later; exclude, to exclude a particular module version from use; and replace, to replace a module version with a different module version.
排除和替換僅適用於主模塊的go.mod，並在依賴項中被忽略。有關詳細信息，請參閱https://research.swtch.com/vgo-mvs。
前導動詞可以從相鄰行中分解出來以創建一個塊，就像在Go導入中一樣：
require ( new/thing v2.3.4 old/thing v1.2.3 )
go.mod文件的設計既可以直接編輯，也可以通過工具輕松更新。'go mod edit'命令可用於從程序和工具中解析和編輯go.mod文件。請參閱'go help mod edit'。
go命令每次使用模塊圖時都會自動更新go.mod，以確保go.mod始終准確地反映現實並且格式正確。例如，考慮這個go.mod文件：
module M require ( A v1 B v1.0.0 C v1.0.0 D v1.2.3 E dev ) exclude D v1.2.3
更新將非規范版本標識符重寫為semver格式，因此A的v1變為v1.0.0，而E的dev變為dev分支上最新提交的偽版本，可能是v0.0.0-20180523231146-b3f5c0f6e5f1。
更新修改了要求以遵守排除，因此對已排除的D v1.2.3的要求將更新為使用D的下一個可用版本，可能是D v1.2.4或D v1.3.0。
此更新消除了冗余或誤導性要求。例如，如果A v1.0.0本身需要B v1.2.0和C v1.0.0，則go.mod對B v1.0.0的要求具有誤導性（由A需要v1.2.0取代），並且要求C v1。 0.0是冗余的（A對同一版本的需要暗示），因此兩者都將被刪除。如果模塊M包含直接從B或C導入包的包，那么將保留需求但更新為正在使用的實際版本。
最后，更新以規范格式重新格式化go.mod，以便將來的機械更改將導致最小的差異。
因為模塊圖定義了import語句的含義，所以加載包的任何命令也都使用並因此更新go.mod，包括go build，go get，go install，go list，go test，go mod graph，go mod tidy，and去mod為什么。
GOPATH環境變量
Go路徑用於解析import語句。它由go / build包實現並記錄。
GOPATH環境變量列出了查找Go代碼的位置。在Unix上，該值是以冒號分隔的字符串。在Windows上，該值是以分號分隔的字符串。在計划9中，值是一個列表。
如果未設置環境變量，GOPATH默認為用戶主目錄中名為“go”的子目錄（在Unix上為$ HOME / go，在Windows上為％USERPROFILE％\ go），除非該目錄包含Go分發。運行“go env GOPATH”查看當前的GOPATH。
請參閱https://golang.org/wiki/SettingGOPATH以設置自定義GOPATH。
GOPATH中列出的每個目錄都必須具有規定的結構：
src目錄包含源代碼。src下面的路徑確定導入路徑或可執行文件名。
pkg目錄包含已安裝的包對象。與Go樹一樣，每個目標操作系統和體系結構對都有自己的子目錄pkg（pkg / GOOS_GOARCH）。
如果DIR是GOPATH中列出的目錄，則可以將包含DIR / src / foo / bar源的包導入為“foo / bar”，並將其編譯形式安裝到“DIR / pkg / GOOS_GOARCH / foo / bar.a” ”。
bin目錄保存已編譯的命令。每個命令都以其源目錄命名，但僅以最終元素命名，而不是整個路徑。也就是說，DIR / src / foo / quux中帶有源的命令安裝在DIR / bin / quux中，而不是DIR / bin / foo / quux中。剝離“foo /”前綴，以便您可以將DIR / bin添加到PATH以獲取已安裝的命令。如果設置了GOBIN環境變量，則命令將安裝到它命名的目錄而不是DIR / bin。GOBIN必須是絕對的道路。
這是一個示例目錄布局：
GOPATH=/home/user/go /home/user/go/ src/ foo/ bar/ (go code in package bar) x.go quux/ (go code in package main) y.go bin/ quux (installed command) pkg/ linux_amd64/ foo/ bar.a (installed package object)
Go搜索GOPATH中列出的每個目錄以查找源代碼，但新包始終下載到列表中的第一個目錄中。
有關示例，請參閱https://golang.org/doc/code.html。
GOPATH和模塊
使用模塊時，GOPATH不再用於解析導入。但是，它仍然用於存儲下載的源代碼（在GOPATH / pkg / mod中）和編譯的命令（在GOPATH / bin中）。
內部目錄
名為“internal”的目錄中或下面的代碼只能由以“internal”的父目錄為根的目錄樹中的代碼導入。這是上面目錄布局的擴展版本：
/home/user/go/ src/ crash/ bang/ (go code in package bang) b.go foo/ (go code in package foo) f.go bar/ (go code in package bar) x.go internal/ baz/ (go code in package baz) z.go quux/ (go code in package main) y.go
z.go中的代碼導入為“foo / internal / baz”，但該import語句只能出現在以foo為根的子樹中的源文件中。源文件foo / f.go，foo / bar / x.go和foo / quux / y.go都可以導入“foo / internal / baz”，但源文件crash / bang / b.go不能。
有關詳細信息，請參閱https://golang.org/s/go14internal。
供應商目錄
Go 1.6包括支持使用外部依賴項的本地副本來滿足這些依賴項的導入，通常稱為vendoring。
名為“vendor”的目錄下的代碼只能由以“vendor”的父目錄為根的目錄樹中的代碼導入，並且只能使用省略前綴並包括vendor元素的導入路徑。
這是上一節中的示例，但將“internal”目錄重命名為“vendor”並添加了新的foo / vendor / crash / bang目錄：
/home/user/go/ src/ crash/ bang/ (go code in package bang) b.go foo/ (go code in package foo) f.go bar/ (go code in package bar) x.go vendor/ crash/ bang/ (go code in package bang) b.go baz/ (go code in package baz) z.go quux/ (go code in package main) y.go
相同的可見性規則適用於內部，但z.go中的代碼導入為“baz”，而不是“foo / vendor / baz”。
源樹中較深的供應商目錄中的代碼在較高目錄中影響代碼。在以foo為根的子樹中，“崩潰/爆炸”的導入解析為“foo / vendor / crash / bang”，而不是頂級“崩潰/爆炸”。
供應商目錄中的代碼不受導入路徑檢查的限制（請參閱“go help importpath”）。
當'go get'檢出或更新git存儲庫時，它現在也會更新子模塊。
供應商目錄不會影響第一次通過“go get”檢出的新存儲庫的位置：這些存儲庫始終位於主GOPATH中，而不是位於供應商子樹中。
有關詳細信息，請參閱https://golang.org/s/go15vendor。
模塊代理協議
默認情況下，go命令直接從版本控制系統下載模塊，就像'go get'一樣。GOPROXY環境變量允許進一步控制下載源。如果未設置GOPROXY，是空字符串，或者是字符串“direct”，則下載使用默認的直接連接到版本控制系統。將GOPROXY設置為“off”不允許從任何來源下載模塊。否則，GOPROXY應該是模塊代理的URL，在這種情況下，go命令將從該代理獲取所有模塊。無論模塊的來源如何，下載的模塊必須與go.sum中的現有條目相匹配（有關驗證的討論，請參閱“go help modules”）。
Go模塊代理是可以響應對指定表單的URL的GET請求的任何Web服務器。請求沒有查詢參數，因此即使是從固定文件系統（包括文件：/// URL）提供服務的站點也可以是模塊代理。
發送到Go模塊代理的GET請求是：
GET $GOPROXY / <module> / @ v / list返回給定模塊的所有已知版本的列表，每行一個。
GET $GOPROXY / <module> / @ v / <version> .info返回有關給定模塊的該版本的JSON格式的元數據。
GET $GOPROXY / <module> / @ v / <version> .mod返回給定模塊的該版本的go.mod文件。
GET $GOPROXY / <module> / @ v / <version> .zip返回給定模塊的該版本的zip存檔。
為了避免在區分大小寫的文件系統中提供問題，<module>和<version>元素是大小寫編碼的，用感嘆號替換每個大寫字母后跟相應的小寫字母：github.com/Azure編碼為github.com/!azure。
關於給定模塊的JSON格式的元數據對應於此Go數據結構，可以在將來進行擴展：
type Info struct { Version string // version string Time time.Time // commit time }
給定模塊的特定版本的zip存檔是標准zip文件，其包含與模塊的源代碼和相關文件對應的文件樹。存檔使用斜杠分隔的路徑，存檔中的每個文件路徑必須以<module> @ <version> /開頭，其中模塊和版本直接替換，而不是大小寫編碼。模塊文件樹的根對應於存檔中的<module> @ <version> /前綴。
即使直接從版本控制系統下載，go命令也會合成顯式的info，mod和zip文件，並將它們存儲在本地緩存中，$ GOPATH / pkg / mod / cache / download，就像它直接從下載它們一樣代理人。緩存布局與代理URL空間相同，因此在（或復制到）https://example.com/proxy上提供$ GOPATH / pkg / mod / cache / download 會讓其他用戶訪問這些緩存的模塊版本GOPROXY = https://example.com/proxy。
導入路徑語法
導入路徑（請參閱“go help packages”）表示存儲在本地文件系統中的包。通常，導入路徑表示標准包（例如“unicode / utf8”）或在其中一個工作空間中找到的包（有關詳細信息，請參閱：'go help gopath'）。
相對導入路徑
以./或../開頭的導入路徑稱為相對路徑。工具鏈以兩種方式支持相對導入路徑作為快捷方式。
首先，相對路徑可以用作命令行上的簡寫。如果您在包含導入為“unicode”的代碼的目錄中工作並且想要運行“unicode / utf8”的測試，則可以鍵入“go test ./utf8”而不是需要指定完整路徑。同樣，在相反的情況下，“go test ..”將從“unicode / utf8”目錄中測試“unicode”。也允許相對模式，例如“go test。/ ...”來測試所有子目錄。有關模式語法的詳細信息，請參閱“go help packages”。
其次，如果您正在編譯不在工作空間中的Go程序，則可以在該程序的import語句中使用相對路徑來引用附近的代碼，而不是在工作空間中。這樣可以很容易地在通常的工作空間之外試驗小型多包裝程序，但是這些程序不能通過“go install”安裝（沒有可以安裝它們的工作空間），所以每次它們都是從頭開始重建的。建成了。為避免歧義，Go程序無法在工作空間中使用相對導入路徑。
遠程導入路徑
某些導入路徑還描述了如何使用修訂控制系統獲取程序包的源代碼。
一些常見的代碼托管站點具有特殊語法：
Bitbucket (Git, Mercurial) import "bitbucket.org/user/project" import "bitbucket.org/user/project/sub/directory" GitHub (Git) import "github.com/user/project" import "github.com/user/project/sub/directory" Launchpad (Bazaar) import "launchpad.net/project" import "launchpad.net/project/series" import "launchpad.net/project/series/sub/directory" import "launchpad.net/~user/project/branch" import "launchpad.net/~user/project/branch/sub/directory" IBM DevOps Services (Git) import "hub.jazz.net/git/user/project" import "hub.jazz.net/git/user/project/sub/directory"
對於托管在其他服務器上的代碼，導入路徑可以使用版本控制類型進行限定，或者go工具可以通過https / http動態獲取導入路徑，並從HTML中的<meta>標記中發現代碼所在的位置。
聲明代碼位置，表單的導入路徑
repository.vcs/path
使用指定的版本控制系統指定具有或不包含.vcs后綴的給定存儲庫，然后指定該存儲庫中的路徑。支持的版本控制系統是：
Bazaar .bzr Fossil .fossil Git .git Mercurial .hg Subversion .svn
例如，
import "example.org/user/foo.hg"
表示example.org/user/foo或foo.hg中的Mercurial存儲庫的根目錄
import "example.org/repo.git/foo/bar"
表示example.org/repo或repo.git中Git存儲庫的foo / bar目錄。
當版本控制系統支持多種協議時，在下載時依次嘗試每種協議。例如，Git下載嘗試https：//，然后是git + ssh：//。
默認情況下，下載僅限於已知的安全協議（例如https，ssh）。要覆蓋Git下載的此設置，可以設置GIT_ALLOW_PROTOCOL環境變量（有關詳細信息，請參閱：“go help environment”）。
如果導入路徑不是已知的代碼托管站點且缺少版本控制限定符，則go工具會嘗試通過https / http獲取導入，並在文檔的HTML <head>中查找<meta>標記。
元標記具有以下形式：
<meta name =“go-import”content =“import-prefix vcs repo-root”>
import-prefix是與存儲庫根目錄對應的導入路徑。它必須是使用“go get”獲取的包的前綴或完全匹配。如果它不是完全匹配，則在前綴處生成另一個http請求以驗證<meta>標記是否匹配。
元標記應盡可能早地出現在文件中。特別是，它應該出現在任何原始JavaScript或CSS之前，以避免混淆go命令的受限解析器。
vcs是“bzr”，“fossil”，“git”，“hg”，“svn”之一。
repo-root是包含方案且不包含.vcs限定符的版本控制系統的根。
例如，
import "example.org/pkg/foo"
將導致以下請求：
https://example.org/pkg/foo?go-get=1（首選） http://example.org/pkg/foo?go-get=1 （后備，僅限-insecure）
如果該頁面包含元標記
<meta name =“go-import”content =“example.org git https://code.org/r/p/exproj ”>
go工具將驗證https://example.org/?go-get=1是否包含相同的元標記，然后git clone https://code.org/r/p/exproj進入GOPATH / src / example.org 。
使用GOPATH時，下載的包將寫入GOPATH環境變量中列出的第一個目錄。（參見'go help gopath-get'和'go help gopath'。）
使用模塊時，下載的包存儲在模塊緩存中。（參見'go help module-get'和'go help goproxy'。）
使用模塊時，會識別go-import元標記的其他變體，並且優先於那些列出版本控制系統。該變體使用“mod”作為內容值中的vcs，如：
<meta name =“go-import”content =“example.org mod https://code.org/moduleproxy ”>
此標記表示從URL https://code.org/moduleproxy上提供的模塊代理獲取帶有以example.org開頭的路徑的模塊。有關代理協議的詳細信息，請參閱“go help goproxy”。
導入路徑檢查
當上述自定義導入路徑功能重定向到已知代碼托管站點時，每個生成的包都有兩個可能的導入路徑，使用自定義域或已知的托管站點。
如果通過對這兩種形式之一的注釋立即跟隨（在下一個換行符之前），則聲稱包語句具有“導入注釋”：
package math // import "path" package math /* import "path" */
go命令將拒絕安裝帶有導入注釋的包，除非該導入路徑引用該包。通過這種方式，導入注釋可以讓包作者確保使用自定義導入路徑，而不是直接指向底層代碼托管站點的路徑。
對供應商樹中的代碼禁用導入路徑檢查。這使得可以將代碼復制到供應商樹中的備用位置，而無需更新導入注釋。
使用模塊時也會禁用導入路徑檢查。導入路徑注釋由go.mod文件的模塊語句廢棄。
有關詳細信息，請參閱https://golang.org/s/go14customimport。
模塊，模塊版本等
模塊是相關Go包的集合。模塊是源代碼交換和版本控制的單元。go命令直接支持使用模塊，包括記錄和解析對其他模塊的依賴性。模塊替換舊的基於GOPATH的方法來指定在給定構建中使用哪些源文件。
初步模塊支持
Go 1.11包括對Go模塊的初步支持，包括一個新的模塊感知'go get'命令。我們打算繼續修改這種支持，同時保持兼容性，直到它可以被宣布為官方（不再是初步的），然后在稍后我們可以刪除對GOPATH工作的支持和舊的'go get'命令。
利用新的Go 1.11模塊支持的最快方法是將您的存儲庫簽出到GOPATH / src之外的目錄中，在那里創建一個go.mod文件（在下一節中描述），並從該文件中運行go命令樹。
對於更精細的控制，Go 1.11中的模塊支持尊重臨時環境變量GO111MODULE，該變量可以設置為三個字符串值之一：off，on或auto（默認值）。如果GO111MODULE = off，則go命令從不使用新模塊支持。相反，它查找供應商目錄和GOPATH以查找依賴項; 我們現在將其稱為“GOPATH模式”。如果GO111MODULE = on，則go命令需要使用模塊，從不咨詢GOPATH。我們將此稱為模塊感知或以“模塊感知模式”運行的命令。如果GO111MODULE = auto或未設置，則go命令根據當前目錄啟用或禁用模塊支持。僅當當前目錄位於GOPATH / src之外並且其本身包含go.mod文件或位於包含go的目錄下時，才啟用模塊支持。
在模塊感知模式下，GOPATH不再定義構建期間導入的含義，但它仍然存儲下載的依賴項（在GOPATH / pkg / mod中）和已安裝的命令（在GOPATH / bin中，除非設置了GOBIN）。
定義一個模塊
模塊由Go源文件樹定義，並在樹的根目錄中包含go.mod文件。包含go.mod文件的目錄稱為模塊根目錄。通常，模塊根目錄也將對應於源代碼存儲庫根目錄（但通常不需要）。該模塊是模塊根目錄及其子目錄中所有Go包的集合，但不包括具有自己的go.mod文件的子樹。
“模塊路徑”是與模塊根對應的導入路徑前綴。go.mod文件定義模塊路徑，並列出在構建期間解析導入時應使用的其他模塊的特定版本，方法是提供模塊路徑和版本。
例如，這個go.mod聲明包含它的目錄是帶有路徑example.com/m的模塊的根目錄，並且它還聲明該模塊依賴於golang.org/x/text和gopkg.in的特定版本。 /yaml.v2：
module example.com/m require（ golang.org/x/text v0.3.0 gopkg.in/yaml.v2 v2.1.0 ）
go.mod文件還可以指定僅在直接構建模塊時應用的替換和排除版本; 當模塊合並到更大的構建中時，它們將被忽略。有關go.mod文件的更多信息，請參閱“go help go.mod”。
要啟動一個新模塊，只需在模塊目錄樹的根目錄中創建一個go.mod文件，該文件只包含一個模塊語句。'go mod init'命令可用於執行此操作：
去mod init example.com/m
在已經使用現有依賴關系管理工具（如godep，glide或dep）的項目中，“go mod init”還將添加與現有配置匹配的require語句。
一旦go.mod文件存在，就不需要額外的步驟：像'go build'，'go test'，甚至'go list'這樣的命令將根據需要自動添加新的依賴項以滿足導入。
主模塊和構建列表
“主模塊”是包含運行go命令的目錄的模塊。go命令通過查找當前目錄中的go.mod或者當前目錄的父目錄，或者父目錄的父目錄等來查找模塊root。
主模塊的go.mod文件定義了go命令可以通過require，replace和exclude語句使用的精確軟件包集。通過以下require語句找到的依賴關系模塊也有助於定義該組包，但只能通過其go.mod文件的require語句：依賴模塊中的任何replace和exclude語句都將被忽略。因此，replace和exclude語句允許主模塊完全控制其自己的構建，而不受依賴項的完全控制。
提供構建包的模塊集稱為“構建列表”。構建列表最初僅包含主模塊。然后，go命令以遞歸方式向列表添加列表中已有模塊所需的確切模塊版本，直到沒有任何內容可添加到列表中。如果將特定模塊的多個版本添加到列表中，則最后僅保留最新版本（根據語義版本排序）以用於構建。
'go list'命令提供有關主模塊和構建列表的信息。例如：
go list -m # print path of main module go list -m -f={{.Dir}} # print root directory of main module go list -m all # print build list
維護模塊要求
go.mod文件是程序員和工具可讀和可編輯的。go命令本身會自動更新go.mod文件，以維護標准格式和require語句的准確性。
任何找到不熟悉的導入的go命令都會查找包含該導入的模塊，並自動將該模塊的最新版本添加到go.mod中。因此，在大多數情況下，只需在源代碼中添加導入並運行“go build”，“go test”，甚至“go list”即可：作為分析包的一部分，go命令將發現並解析導入並更新go.mod文件。
任何go命令都可以確定缺少模塊要求並且必須添加，即使僅考慮模塊中的單個包也是如此。另一方面，確定不再需要並且可以刪除模塊要求需要在所有可能的構建配置（體系結構，操作系統，構建標記等）中完整查看模塊中的所有包。'go mod tidy'命令構建該視圖，然后添加任何缺少的模塊要求並刪除不必要的模塊要求。
作為在go.mod中維護require語句的一部分，go命令跟蹤哪些提供由當前模塊直接導入的包，哪些提供僅由其他模塊依賴性間接使用的包。僅在間接使用時需要的要求在go.mod文件中標有“// indirect”注釋。一旦其他直接要求暗示間接要求，就會自動從go.mod文件中刪除。間接要求僅在使用未能說明其某些自身依賴關系的模塊或在其自己聲明的要求之前明確升級模塊的依賴關系時出現。
由於這種自動維護，go.mod中的信息是構建的最新可讀描述。
'go get'命令更新go.mod以更改構建中使用的模塊版本。升級一個模塊可能意味着升級其他模塊，同樣一個模塊的降級可能意味着降級其他模塊。'go get'命令也會產生這些隱含的變化。如果直接編輯go.mod，“go build”或“go list”等命令將假定升級是預期的，並自動進行任何隱含的升級並更新go.mod以反映它們。
'go mod'命令提供了用於維護和理解模塊和go.mod文件的其他功能。請參閱'go help mod'。
-mod build標志提供了對go.mod更新和使用的額外控制。
如果使用-mod = readonly調用，則不允許從上述go.mod的隱式自動更新中執行go命令。相反，當需要對go.mod進行任何更改時，它會失敗。此設置對於檢查go.mod是否不需要更新非常有用，例如在持續集成和測試系統中。即使使用-mod = readonly，“go get”命令仍然允許更新go.mod，而“go mod”命令不接受-mod標志（或任何其他構建標志）。
如果使用-mod = vendor調用，則go命令假定供應商目錄包含正確的依賴項副本，並忽略go.mod中的依賴項描述。
偽版本
go.mod文件和go命令通常使用語義版本作為描述模塊版本的標准形式，因此可以比較版本以確定哪個版本應該比其他版本更早或更晚。通過在底層源存儲庫中標記修訂版來引入類似v1.2.3的模塊版本。可以使用像v0.0.0-yyyymmddhhmmss-abcdefabcdef這樣的“偽版本”來引用未標記的修訂，其中時間是UTC的提交時間，最后的后綴是提交哈希的前綴。時間部分確保可以比較兩個偽版本以確定稍后發生的版本，提交哈希標識基礎提交，並且前綴（在此示例中為v0.0.0-）是從提交圖中的最新標記版本派生的在此提交之前。
有三種偽版本形式：
當目標提交之前沒有具有適當主要版本的早期版本化提交時，將使用vX.0.0-yyyymmddhhmmss-abcdefabcdef。（這最初是唯一的形式，因此一些較舊的go.mod文件甚至可以使用此表單來執行跟隨標記的提交。）
當目標提交之前的最新版本化提交是vX.YZ-pre時，使用vX.YZ-pre.0.yyyymmddhhmmss-abcdefabcdef。
當目標提交之前的最新版本化提交是vX.YZ時，使用vX.Y.（Z + 1）-0.yyyymmddhhmmss-abcdefabcdef。
偽版本永遠不需要手動輸入：go命令將接受普通提交哈希並自動將其轉換為偽版本（或標記版本，如果可用）。此轉換是模塊查詢的示例。
模塊查詢
go命令在命令行和主模塊的go.mod文件中接受“模塊查詢”來代替模塊版本。（在評估主模塊的go.mod文件中找到的查詢后，go命令會更新文件以將查詢替換為其結果。）
完全指定的語義版本（例如“v1.2.3”）將評估該特定版本。
語義版本前綴（例如“v1”或“v1.2”）將評估具有該前綴的最新可用標記版本。
語義版本比較（例如“<v1.2.3”或“> = v1.5.6”）評估最接近比較目標的可用標記版本（<和<=的最新版本，>和>的最早版本=）。
字符串“latest”與最新的可用標記版本匹配，或者與底層源存儲庫的最新未標記版本匹配。
底層源存儲庫的修訂標識符（例如提交哈希前綴，修訂標記或分支名稱）選擇該特定代碼修訂。如果修訂版還標記了語義版本，則查詢將評估該語義版本。否則，查詢將評估為提交的偽版本。
所有查詢都喜歡發布版本到預發布版本。例如，“<v1.2.3”將更喜歡返回“v1.2.2”而不是“v1.2.3-pre1”，即使“v1.2.3-pre1”更接近比較目標。
主模塊go.mod中的exclude語句不允許的模塊版本被視為不可用，並且查詢無法返回。
例如，這些命令都是有效的：
go get github.com/gorilla/mux@latest # same (@latest is default for 'go get') go get github.com/gorilla/mux@v1.6.2 # records v1.6.2 go get github.com/gorilla/mux@e3702bed2 # records v1.6.2 go get github.com/gorilla/mux@c856192 # records v0.0.0-20180517173623-c85619274f5d go get github.com/gorilla/mux@master # records current meaning of master
模塊兼容性和語義版本控制
go命令要求模塊使用語義版本並期望版本准確地描述兼容性：它假定v1.5.4是v1.5.3，v1.4.0甚至v1.0.0的向后兼容替代品。更常見的是，go命令期望包遵循“導入兼容性規則”，其中說：
“如果舊軟件包和新軟件包具有相同的導入路徑，則新軟件包必須向后兼容舊軟件包。”
由於go命令采用導入兼容性規則，因此模塊定義只能設置其依賴項之一的最低要求版本：它無法設置最大值或排除所選版本。但是，導入兼容性規則並不能保證：v1.5.4可能是錯誤的，而不是v1.5.3的向后兼容替代品。因此，go命令永遠不會從舊版本更新到未安裝的模塊的較新版本。
在語義版本控制中，更改主版本號表示缺少與早期版本的向后兼容性。為了保持導入兼容性，go命令要求主要版本為v2或更高版本的模塊使用具有該主要版本的模塊路徑作為最終元素。例如，example.com/m的v2.0.0版必須使用模塊路徑example.com/m/v2，該模塊中的包將使用該路徑作為其導入路徑前綴，如example.com/m/v2 /子/ PKG。以這種方式包括模塊路徑中的主要版本號和導入路徑稱為“語義導入版本控制”。主要版本為v2及更高版本的模塊的偽版本以該主要版本而非v0開頭，如v2.0.0-20180326061214-4fc5987536ef。
作為一種特殊情況，以gopkg.in/開頭的模塊路徑繼續使用在該系統上建立的約定：主要版本始終存在，並且前面有一個點而不是斜杠：gopkg.in/yaml.v1和gopkg.in/yaml.v2，而不是gopkg.in/yaml和gopkg.in/yaml/v2。
go命令將具有不同模塊路徑的模塊視為不相關：它在example.com/m和example.com/m/v2之間沒有任何連接。具有不同主要版本的模塊可以在構建中一起使用，並且由於它們的包使用不同的導入路徑而保持獨立。
在語義版本控制中，主要版本v0用於初始開發，表示沒有期望穩定性或向后兼容性。主要版本v0沒有出現在模塊路徑中，因為這些版本是為v1.0.0做准備，並且v1也沒有出現在模塊路徑中。
在引入語義導入版本控制約定之前編寫的代碼可以使用主要版本v2和更高版本來描述與v0和v1中使用的相同的未版本化導入路徑集。為了適應這樣的代碼，如果源代碼存儲庫對於沒有go.mod的文件樹具有v2.0.0或更高版本的標記，則該版本被認為是v1模塊的可用版本的一部分，並且在轉換時被賦予+不兼容的后綴到模塊版本，如在v2.0.0 +不兼容。+不兼容標記也適用於從此類版本派生的偽版本，如v2.0.1-0.yyyymmddhhmmss-abcdefabcdef +不兼容。
通常，在v0版本，預發行版本，偽版本或+不兼容版本上的構建列表中具有依賴性（由“go list -m all”報告）表明升級時出現問題的可能性更大這種依賴性，因為沒有期望兼容性。
見https://research.swtch.com/vgo-import關於語義進口版本的更多信息，並查看https://semver.org/更多關於語義版本。
模塊代碼布局
現在，請參閱https://research.swtch.com/vgo-module，以獲取有關如何將版本控制系統中的源代碼映射到模塊文件樹的信息。
模塊下載和驗證
go命令在主模塊的根目錄中與go.mod一起維護一個名為go.sum的文件，其中包含特定模塊版本內容的預期加密校驗和。每次使用依賴項時，如果缺少，則將其校驗和添加到go.sum，或者需要匹配go.sum中的現有條目。
go命令維護下載包的緩存，並在下載時計算和記錄每個包的加密校驗和。在正常操作中，go命令會針對主模塊的go.sum文件檢查這些預先計算的校驗和，而不是在每次命令調用時重新計算它們。'go mod verify'命令檢查模塊下載的緩存副本是否仍然匹配記錄的校驗和和go.sum中的條目。
根據GOPROXY環境變量的設置，go命令可以從代理獲取模塊，而不是直接連接到源控制系統。
有關代理的詳細信息以及緩存的已下載軟件包的格式，請參閱“go help goproxy”。
模塊和銷售
使用模塊時，go命令完全忽略供應商目錄。
默認情況下，go命令通過從其源下載模塊並使用下載的副本來滿足依賴性（在驗證之后，如上一節中所述）。為了允許與舊版本的Go進行互操作，或者為了確保用於構建的所有文件一起存儲在單個文件樹中，'go mod vendor'在主模塊的根目錄中創建一個名為vendor的目錄並存儲在那里來自依賴模塊的包，這些包是支持主模塊中包的構建和測試所需的。
要使用主模塊的頂級供應商目錄來構建以滿足依賴性（禁用常用網絡源和本地緩存的使用），請使用“go build -mod = vendor”。請注意，僅使用主模塊的頂級供應商目錄; 其他位置的供應商目錄仍被忽略。
模塊感知go get
'go get'命令根據go命令是在模塊感知模式還是傳統GOPATH模式下運行來改變行為。即使在傳統的GOPATH模式下，此幫助文本也可以作為“go help module-get”訪問，它描述了“go get”，因為它在模塊感知模式下運行。
用法：go get [-d] [-m] [-u] [-v] [-insecure] [build flags] [packages]
獲取解析並將依賴項添加到當前開發模塊，然后構建並安裝它們。
第一步是解決要添加的依賴項。
對於每個命名的包或包模式，get必須決定使用哪個版本的相應模塊。默認情況下，get選擇最新的標記發行版本，例如v0.4.5或v1.2.3。如果沒有標記的發行版本，請選擇最新的標記預發布版本，例如v0.0.1-pre1。如果根本沒有標記版本，請選擇最新的已知提交。
可以通過在package參數中添加@version后綴來覆蓋此默認版本選擇，如'go get golang.org/x/text@v0.3.0'。對於存儲在源控制存儲庫中的模塊，版本后綴也可以是提交哈希，分支標識符或源控制系統已知的其他語法，如'go get golang.org/x/text@master'。版本后綴@latest顯式請求上述默認行為。
如果正在考慮的模塊已經是當前開發模塊的依賴項，那么get將更新所需的版本。指定早於當前所需版本的版本是有效的，並降低依賴性。版本后綴@none表示應根據需要完全刪除依賴項，降級或刪除模塊。
雖然默認使用包含命名包的模塊的最新版本，但它不使用該模塊的最新版本的依賴項。相反，它更喜歡使用該模塊請求的特定依賴版本。例如，如果最新的A需要模塊B v1.2.3，而B v1.2.4和v1.3.1也可用，那么'go get A'將使用最新的A但是然后使用B v1.2.3，按照A的要求。（如果對特定模塊有競爭要求，那么'go get'通過獲取最大請求版本來解決這些要求。）
-u標志指示get更新依賴關系以在可用時使用較新的次要或補丁版本。繼續前面的例子，'go get -u A'將使用最新的A與B v1.3.1（不是B v1.2.3）。
-u = patch標志（不是-u patch）指示get更新依賴關系以在可用時使用更新的補丁版本。繼續前面的例子，'go get -u = patch A'將使用最新的A和B v1.2.4（不是B v1.2.3）。
通常，添加新的依賴項可能需要升級現有的依賴項以保持工作的構建，並且“go get”會自動執行此操作。同樣，降級一個依賴項可能需要降級其他依賴項，“go get”也會自動執行此操作。
在解析，升級和降級模塊以及更新go.mod之后，-m標志指示get停在這里。使用-m時，每個指定的包路徑也必須是模塊路徑，而不是模塊根目錄下的包的導入路徑。
-insecure標志允許從存儲庫中提取並使用不安全的方案（如HTTP）解析自定義域。謹慎使用。
第二步是下載（如果需要），構建和安裝命名包。
如果參數命名模塊但不命名包（因為模塊的根目錄中沒有Go源代碼），則跳過該參數的安裝步驟，而不是導致構建失敗。例如，即使沒有與該導入路徑對應的代碼，'go get golang.org/x/perf'也會成功。
請注意，允許使用包模式，並在解析模塊版本后進行擴展。例如，'go get golang.org/x/perf/cmd / ...'添加最新的golang.org/x/perf，然后在最新版本中安裝命令。
-d標志指示get下載構建命名包所需的源代碼，包括下載必要的依賴項，但不構建和安裝它們。
如果沒有包參數，則“go get”將應用於主模塊，並應用於當前目錄中的Go包（如果有）。特別是，'go get -u'和'go get -u = patch'更新主模塊的所有依賴項。沒有包參數也沒有-u，'go get'不僅僅是'go install'，'go get -d'不僅僅是'go list'。
有關模塊的更多信息，請參閱“go help modules”。
有關指定包的更多信息，請參閱“go help packages”。
本文描述了使用模塊來管理源代碼和依賴關系的行為。如果go命令在GOPATH模式下運行，則get的標志和效果的細節會發生變化，就像'go help get'一樣。請參閱'go help modules'和'go help gopath-get'。
另見：go build，go install，go clean，go mod。
包列表和模式
許多命令適用於一組包：
go action [packages]
通常，[packages]是導入路徑列表。
導入路徑是根路徑或以a開頭的路徑。或..元素被解釋為文件系統路徑，表示該目錄中的包。
否則，導入路徑P表示在GOPATH環境變量中列出的某些DIR的目錄DIR / src / P中找到的包（有關更多詳細信息，請參閱：'go help gopath'）。
如果未指定導入路徑，則該操作將應用於當前目錄中的包。
路徑有四個保留名稱，不應該用於使用go工具構建的包：
- “main”表示獨立可執行文件中的頂級包。
- “all”擴展到所有GOPATH樹中的所有包。例如，'go list all'列出本地系統上的所有軟件包。使用模塊時，“all”擴展到主模塊中的所有包及其依賴關系，包括任何這些包的測試所需的依賴關系。
- “std”就像擴展到標准Go庫中的包一樣。
- “cmd”擴展為Go存儲庫的命令及其內部庫。
以“cmd /”開頭的導入路徑僅匹配Go存儲庫中的源代碼。
導入路徑是一種模式，如果它包含一個或多個“...”通配符，每個通配符都可以匹配任何字符串，包括空字符串和包含斜杠的字符串。這樣的模式擴展到GOPATH樹中找到的所有包目錄，其名稱與模式匹配。
為了使普通模式更方便，有兩種特殊情況。首先，/ ...在模式的末尾可以匹配一個空字符串，以便net / ...匹配其子目錄中的net和packages，如net / http。其次，任何包含通配符的斜杠分隔模式元素都不會參與vendored包路徑中“vendor”元素的匹配，因此./ ...與./vendor或./的子目錄中的包不匹配。 mycode / vendor，但./vendor / ...和./mycode/vendor / ... do。但請注意，名為vendor的目錄本身包含代碼不是銷售包：cmd / vendor將是名為vendor的命令，並且模式cmd / ...與它匹配。有關vendoring的更多信息，請參閱golang.org/s/go15vendor。
導入路徑還可以命名要從遠程存儲庫下載的包。運行'go help importpath'了解詳細信息。
程序中的每個包都必須具有唯一的導入路徑。按照慣例，這是通過使用屬於您的唯一前綴啟動每個路徑來安排的。例如，Google內部使用的路徑都以“google”開頭，而表示遠程存儲庫的路徑則以代碼的路徑開頭，例如“github.com/user/repo”。
程序中的包不需要具有唯一的包名，但有兩個具有特殊含義的保留包名。名稱main表示命令，而不是庫。命令內置於二進制文件中，無法導入。名稱文檔表示目錄中非Go程序的文檔。go命令會忽略包文檔中的文件。
作為一種特殊情況，如果包列表是來自單個目錄的.go文件列表，則該命令將應用於由這些文件組成的單個合成包，忽略這些文件中的任何構建約束並忽略其中的任何其他文件。目錄。
以“。”開頭的目錄和文件名。go工具忽略或“_”，名為“testdata”的目錄也是如此。
測試標志
'go test'命令接受適用於'go test'本身的兩個標志和適用於生成的測試二進制文件的標志。
幾個標志控制分析並編寫適合“go tool pprof”的執行配置文件; 運行“go tool pprof -h”獲取更多信息。pprof的--alloc_space，--alloc_objects和--show_bytes選項控制信息的呈現方式。
'go test'命令識別以下標志並控制任何測試的執行：
-bench regexp 僅運行與正則表達式匹配的基准。 默認情況下，不運行基准測試。 要運行所有基准測試，請使用'-bench'。或'-bench =。'。 正則表達式由未括號的斜杠（/） 字符拆分為正則表達式序列，並且 基准測試標識符的每個部分必須與 序列中的相應元素匹配（如果有）。可能的匹配父項 以bN = 1運行以識別子基准。例如， 給定-bench = X / Y，匹配X的頂級基准測試 以bN = 1 運行，以找到與Y匹配的任何子基准， 然后完全運行。 -benchtime t 運行每個基准測試的足夠迭代以獲取t，指定 為time.Duration（例如，-benchtime 1h30s）。 默認值為1秒（1秒）。 特殊語法Nx意味着運行基准N次 （例如，-benchtime 100x）。 -count n 運行每個測試和基准n次（默認值1）。 如果設置了-cpu，則為每個GOMAXPROCS值運行n次。 示例總是運行一次。 -cover 啟用覆蓋率分析。 請注意，因為覆蓋率通過 在編譯之前注釋源代碼來工作，所以 啟用覆蓋率的編譯和測試失敗可能會報告不對應的行號 原始來源。 -covermode set，count，atomic 設置 正在測試的軟件包的覆蓋率分析模式。除非啟用了-race，否則默認為“set”， 在這種情況下它是“原子”。 值： set：bool：這個語句運行嗎？ count：int：這個語句運行了多少次？ atomic：int：count，但在多線程測試中是正確的; 顯着更貴。 設置 - 覆蓋。 -coverpkg pattern1，pattern2，pattern3 將每個測試中的覆蓋率分析應用於與模式匹配的包。 默認情況是每個測試僅分析正在測試的包。 有關包模式的說明，請參閱“go help packages”。 設置 - 覆蓋。 -cpu 1,2,4 指定 應為其執行測試或基准測試的GOMAXPROCS值列表。默認值 是GOMAXPROCS 的當前值。 -failfast 在第一次測試失敗后不要開始新的測試。 -list regexp 列出與正則表達式匹配的測試，基准或示例。 不會運行測試，基准測試或示例。這只 列出頂級測試。不會顯示子測試或子基准測試。 -parallel n 允許並行執行調用t.Parallel的測試函數。 該標志的值是 同時運行的最大測試數; 默認情況下，它設置為GOMAXPROCS的值。 請注意，-parallel僅適用於單個測試二進制文件。 'go test'命令也可以 根據-p標志的設置並行運行不同包的測試 （參見'go help build'）。 -run regexp 僅運行與正則表達式匹配的那些測試和示例。 對於測試，正則表達式由未括號的斜杠（/） 字符拆分為正則表達式序列，並且 測試標識符的每個部分必須與相應的元素匹配。 順序，如果有的話。請注意，匹配的可能父項也會 運行，因此-run = X / Y匹配並運行並報告 與X匹配的所有測試的結果，即使沒有匹配Y的子測試的結果， 因為它必須運行它們以查找那些-tests。 -short 告訴長時間運行的測試以縮短其運行時間。 默認情況下它處於關閉狀態，但在all.bash期間設置，以便安裝 Go樹可以運行完整性檢查但不花時間運行 詳盡的測試。 -timeout d 如果測試二進制文件的運行時間超過持續時間d，則發生混亂。 如果d為0，則禁用超時。 默認值為10分鍾（10米）。 -v 詳細輸出：記錄運行時的所有測試。 即使測試成功，也會打印Log和Logf調用中的所有文本。 -vet list 在“go test”期間配置“go vet”的調用， 以使用以逗號分隔的獸醫檢查列表。 如果list為空，則“go test”運行“go vet”，其中列出了一系列 被認為總是值得解決的檢查。 如果列表是“關閉”，則“go test”根本不會運行“go vet”。
以下標志也可以通過'go test'識別，並可用於在執行期間對測試進行分析：
-benchmem 打印基准的內存分配統計信息。 -blockprofile block.out 在所有測試完成后 ，將goroutine阻塞配置文件寫入指定的文件。 將測試二進制文件寫為-c will。 -blockprofilerate n 通過 使用n調用runtime.SetBlockProfileRate來控制goroutine阻塞配置文件中提供的詳細信息。 請參閱'go doc runtime.SetBlockProfileRate'。 分析器的目的是平均每隔 n納秒對程序所阻塞的一個阻塞事件進行采樣。默認情況下， 如果設置了-test.blockprofile而沒有此標志， 則會記錄所有阻塞事件，相當於-test.blockprofilerate = 1。 -coverprofile cover.out 在所有測試通過后，將覆蓋配置文件寫入文件。 設置 - 覆蓋。 -cpuprofile cpu.out 在退出之前將CPU配置文件寫入指定的文件。 將測試二進制文件寫為-c will。 -memprofile mem.out 在所有測試通過后將分配配置文件寫入文件。 將測試二進制文件寫為-c will。 -memprofilerate n 通過 設置runtime.MemProfileRate，啟用更精確（和昂貴）的內存分配配置文件。請參閱'go doc runtime.MemProfileRate'。 要分析所有內存分配，請使用-test.memprofilerate = 1。 -mutexprofile mutex.out 所有測試完成后 ，將互斥鎖爭用配置文件寫入指定的文件。 將測試二進制文件寫為-c will。 -mutexprofilefraction n n堆棧中的樣本1，包含 爭用互斥鎖的goroutines 。 -outputdir目錄 將分析中的輸出文件放在指定目錄中， 默認情況下是運行“go test”的目錄。 -trace trace.out 在退出之前將執行跟蹤寫入指定的文件。
這些標志中的每一個也通過可選的“測試”識別。前綴，如-test.v. 但是，當直接調用生成的測試二進制文件（'go test -c'的結果）時，前綴是必需的。
在調用測試二進制文件之前，'go test'命令在可選包列表之前和之后，根據需要重寫或刪除已識別的標志。
例如，命令
go test -v -myflag testdata -cpuprofile = prof.out -x
將編譯測試二進制文件，然后運行它
pkg.test -test.v -myflag testdata -test.cpuprofile = prof.out
（-x標志被刪除，因為它僅適用於go命令的執行，而不適用於測試本身。）
生成配置文件的測試標志（覆蓋范圍除外）也會將測試二進制文件保留在pkg.test中，以便在分析配置文件時使用。
當'go test'運行測試二進制文件時，它會從相應軟件包的源代碼目錄中執行。根據測試，在直接調用生成的測試二進制文件時可能需要執行相同操作。
命令行程序包列表（如果存在）必須出現在go test命令未知的任何標志之前。繼續上面的例子，包列表必須出現在-myflag之前，但可能出現在-v的兩側。
當'go test'在包列表模式下運行時，'go test'會緩存成功的包測試結果，以避免不必要的重復運行測試。要禁用測試緩存，請使用除可緩存標志之外的任何測試標志或參數。顯式禁用測試緩存的慣用方法是使用-count = 1。
要保持測試二進制文件的參數不被解釋為已知標志或包名稱，請使用-args（請參閱“go help test”），它將命令行的其余部分傳遞給未解釋且未更改的測試二進制文件。
例如，命令
go test -v -args -x -v
將編譯測試二進制文件，然后運行它
pkg.test -test.v -x -v
同樣的，
go test -args math
將編譯測試二進制文件，然后運行它
pkg.test math
在第一個示例中，-x和第二個-v不變地傳遞給測試二進制文件，並且對go命令本身沒有影響。在第二個示例中，參數math被傳遞給測試二進制文件，而不是被解釋為包列表。
測試功能
'go test'命令期望在與測試包對應的“* _test.go”文件中找到測試，基准和示例函數。
一個名為TestXxx的測試函數（其中Xxx不以小寫字母開頭）並且應該具有簽名，
func TestXxx（t * testing.T）{...}
基准函數是名為BenchmarkXxx的函數，應具有簽名，
func BenchmarkXxx（b * testing.B）{...}
示例函數類似於測試函數，但不是使用* testing.T來報告成功或失敗，而是將輸出打印到os.Stdout。如果函數中的最后一個注釋以“Output：”開頭，那么輸出將與注釋完全比較（參見下面的示例）。如果最后一條注釋以“無序輸出：”開頭，則將輸出與注釋進行比較，但忽略行的順序。沒有此類注釋的示例已編譯但未執行。“Output：”之后沒有文本的示例被編譯，執行，並且預期不會產生輸出。
Godoc顯示ExampleXxx的主體以演示函數，常量或變量Xxx的使用。具有接收器類型T或* T的方法M的示例被命名為ExampleT_M。給定函數，常量或變量可能有多個示例，由尾隨_xxx區分，其中xxx是不以大寫字母開頭的后綴。
以下是一個示例示例：
func ExamplePrintln() { Println("The output of\nthis example.") // Output: The output of // this example. }
這是另一個忽略輸出順序的例子：
func ExamplePerm() { for _, value := range Perm(4) { fmt.Println(value) } // Unordered output: 4 // 2 // 1 // 3 // 0 }
當整個測試文件包含單個示例函數，至少一個其他函數，類型，變量或常量聲明，以及沒有測試或基准函數時，它們將作為示例顯示。
有關更多信息，請參閱測試包的文檔。