Go命令官方指南【原譯】

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>」。github

啓動錯誤報告

用法：golang

go bug

Bug打開默認瀏覽器並啓動新的錯誤報告。該報告包含有用的系統信息。正則表達式

編譯包和依賴項

用法：shell

go build [-o output] [-i] [build flags] [packages]

Build會編譯導入路徑命名的包及其依賴項，但不會安裝結果。編程

若是構建的參數是.go文件的列表，則build會將它們視爲指定單個包的源文件列表。json

編譯單個主程序包時，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
}