go

Documentation

Overview

Goは、Goのソースコードを管理するためのツールです。

使用法:

go <コマンド> [引数]

コマンドは以下の通りです:

bug         バグレポートを開始する
build       パッケージと依存関係をコンパイルする
clean       オブジェクトファイルとキャッシュファイルを削除する
doc         パッケージまたはシンボルのドキュメンテーションを表示する
env         Goの環境情報を表示する
fix         パッケージを更新して新しいAPIを使用する
fmt         gofmt（再フォーマット）パッケージソース
generate    ソースを処理してGoのファイルを生成する
get         現在のモジュールに依存関係を追加し、それらをインストールする
install     パッケージと依存関係をコンパイルし、インストールする
list        パッケージまたはモジュールをリストする
mod         モジュールのメンテナンス
work        ワークスペースのメンテナンス
run         Goのプログラムをコンパイルして実行する
test        パッケージをテストする
tool        指定されたgoツールを実行する
version     Goのバージョンを表示する
vet         パッケージのおそらく間違いを報告する

"go help <コマンド>"を使用して、コマンドの詳細情報を取得します。

追加のヘルプトピック:

buildconstraint ビルド制約
buildmode       ビルドモード
c               GoとC間の呼び出し
cache           ビルドとテストのキャッシュ
environment     環境変数
filetype        ファイルタイプ
go.mod          go.modファイル
gopath          GOPATH環境変数
gopath-get      旧式のGOPATH go get
goproxy         モジュールプロキシプロトコル
importpath      インポートパスの構文
modules         モジュール、モジュールバージョンなど
module-get      モジュール対応のgo get
module-auth     go.sumを使用したモジュール認証
packages        パッケージリストとパターン
private         非公開コードのダウンロード設定
testflag        テストフラグ
testfunc        テスト関数
vcs             GOVCSでバージョン管理を制御

"go help <トピック>"を使用して、そのトピックに関する詳細情報を取得します。

バグレポートを開始する

使用法:

go bug

Bugはデフォルトのブラウザを開き、新しいバグレポートを開始します。 レポートには、役立つシステム情報が含まれます。

パッケージと依存関係をコンパイルする

使用法:

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

Buildは、インポートパスで指定されたパッケージとその依存関係をコンパイルしますが、 結果はインストールされません。

buildへの引数が単一のディレクトリからの.goファイルのリストである場合、 buildはそれらを単一のパッケージを指定するソースファイルのリストとして扱います。

パッケージをコンパイルするとき、buildは'_test.go'で終わるファイルを無視します。

単一のmainパッケージをコンパイルするとき、buildは 結果となる実行可能ファイルを最初のソースファイルの名前で出力ファイルに書き込みます ('go build ed.go rx.go'は 'ed'または 'ed.exe'を書き込みます) またはソースコードディレクトリ('go build unix/sam'は 'sam'または 'sam.exe'を書き込みます)。 '.exe'のサフィックスはWindowsの実行可能ファイルを書き込むときに追加されます。

複数のパッケージをコンパイルするか、単一の非mainパッケージをコンパイルするとき、 buildはパッケージをコンパイルしますが、結果となるオブジェクトは破棄し、 パッケージがビルド可能であることをチェックするだけです。

-oフラグは、buildに結果となる実行可能ファイルまたはオブジェクトを 名前付きの出力ファイルまたはディレクトリに書き込むように強制します、 これは最後の2つの段落で説明されたデフォルトの動作とは異なります。 名前付きの出力が既存のディレクトリであるか、 スラッシュまたはバックスラッシュで終わる場合、結果となる実行可能ファイルは そのディレクトリに書き込まれます。

ビルドフラグは、build、clean、get、install、list、run、 およびtestコマンドで共有されます：

-C dir
	コマンドを実行する前にdirに移動します。
	コマンドラインで指定された任意のファイルは、
	ディレクトリを変更した後で解釈されます。
	使用する場合、このフラグはコマンドラインの最初のものでなければなりません。
-a
	すでに最新のパッケージの再ビルドを強制します。
-n
	コマンドを表示しますが、実行はしません。
-p n
	ビルドコマンドやテストバイナリなどのプログラムが、
	並行して実行できる数です。
	デフォルトはGOMAXPROCSで、通常は利用可能なCPUの数です。
-race
	データ競合の検出を有効にします。
	linux/amd64、freebsd/amd64、darwin/amd64、darwin/arm64、windows/amd64、
	linux/ppc64le、およびlinux/arm64（48ビットVMAのみ）でのみサポートされています。
-msan
	メモリサニタイザとの相互運用を有効にします。
	linux/amd64、linux/arm64、freebsd/amd64でのみサポートされています
	そしてホストCコンパイラとしてClang/LLVMのみ。
	すべてのプラットフォームでPIEビルドモードが使用されます（linux/amd64を除く）。
-asan
	アドレスサニタイザとの相互運用を有効にします。
	linux/arm64、linux/amd64でのみサポートされています。
	GCC 7以降、またはClang/LLVM 9以降がある場合にのみ、linux/amd64またはlinux/arm64でサポートされています。
-cover
	コードカバレッジ計測を有効にします。
-covermode set,count,atomic
	カバレッジ分析のモードを設定します。
	デフォルトは "set" ですが、-raceが有効になっている場合は "atomic" です。
	値：
	set: bool: このステートメントは実行されますか？
	count: int: このステートメントは何回実行されますか？
	atomic: int: count、ただしマルチスレッドテストでは正確です。
		かなり高価です。
	-coverを設定します。
-coverpkg pattern1,pattern2,pattern3
	'メイン'パッケージをターゲットとするビルド（つまり、Go実行可能ファイルをビルドする）の場合、
	各パターンに一致するパッケージに対してカバレッジ分析を適用します。
	デフォルトでは、メインのGoモジュール内のパッケージにカバレッジ分析を適用します。
	パッケージパターンの説明については、「go help packages」を参照してください。-coverを設定します。
-v
	コンパイルされるパッケージの名前を表示します。
-work
	一時的な作業ディレクトリの名前を表示し、
	終了時にそれを削除しません。
-x
	コマンドを表示します。
-asmflags '[pattern=]arg list'
	各go tool asm呼び出しに渡す引数。
-buildmode mode
	使用するビルドモード。詳細については、「go help buildmode」を参照してください。
-buildvcs
	バイナリにバージョン管理情報をスタンプするかどうか
	（"true"、"false"、または "auto"）。デフォルト（"auto"）では、メインパッケージ、
	それを含むメインモジュール、および現在のディレクトリがすべて同じリポジトリにある場合、
	バージョン管理情報がバイナリにスタンプされます。
	常にバージョン管理情報を省略するには、-buildvcs=falseを使用します。また、
	バージョン管理情報が利用可能であるが、ツールが欠けているかディレクトリ構造が曖昧であるために
	含めることができない場合にエラーを出すには、-buildvcs=trueを使用します。
-compiler name
	使用するコンパイラの名前、runtime.Compiler（gccgoまたはgc）と同様。
-gccgoflags '[pattern=]arg list'
	各gccgoコンパイラ/リンカー呼び出しに渡す引数。
-gcflags '[pattern=]arg list'
	各go tool compile呼び出しに渡す引数。
-installsuffix suffix
	パッケージインストールディレクトリの名前に使用する接尾辞、
	デフォルトのビルドから出力を分けて保持するため。
	-raceフラグを使用している場合、インストール接尾辞は自動的にraceに設定されます
	または、明示的に設定されている場合、_raceが追加されます。同様に-msan
	および-asanフラグについても同様です。デフォルト以外のコンパイル
	フラグが必要な-buildmodeオプションを使用すると、同様の効果があります。
-ldflags '[pattern=]arg list'
	各go tool link呼び出しに渡す引数。
-linkshared
	-buildmode=sharedで以前に作成された共有ライブラリに対してリンクされるコードをビルドします。
-mod mode
	使用するモジュールのダウンロードモード: readonly、vendor、またはmod。
	デフォルトでは、vendorディレクトリが存在し、go.modのgoバージョンが1.14以上の場合、
	goコマンドは-mod=vendorが設定されているかのように動作します。
	それ以外の場合、goコマンドは-mod=readonlyが設定されているかのように動作します。
	詳細はhttps://golang.org/ref/mod#build-commandsを参照してください。
-modcacherw
	モジュールキャッシュ内の新しく作成されたディレクトリを読み取り専用ではなく、
	読み書き可能にします。
-modfile file
	モジュール対応モードでは、モジュールのルートディレクトリにあるものではなく、
	代替のgo.modファイルを読み込み（および可能な場合は書き込み）します。
	"go.mod"という名前のファイルは、モジュールのルートディレクトリを決定するために
	存在していなければなりませんが、アクセスされません。
	-modfileが指定されている場合、代替のgo.sumファイルも使用されます。
	そのパスは、".mod"拡張子をトリミングして".sum"を追加することで-modfileフラグから派生します。
-overlay file
	ビルド操作のオーバーレイを提供するJSON設定ファイルを読み込みます。
	ファイルは、'Replace'という名前の単一のフィールドを持つJSON構造で、
	各ディスクファイルパス（文字列）をそのバッキングファイルパスにマッピングします。
	これにより、ビルドはディスクファイルパスがバッキングファイルパスによって与えられた内容で存在するかのように、
	またはバッキングファイルパスが空の場合はディスクファイルパスが存在しないかのように実行されます。
	-overlayフラグのサポートにはいくつかの制限があります。
	重要な点として、インクルードパスの外部から含まれるcgoファイルは、それらが含まれるGoパッケージと同じディレクトリに
	存在しなければならず、オーバーレイはgo runおよびgo testを通じて実行されるバイナリとテストには表示されません。
-pgo file
	プロファイルガイド付き最適化（PGO）のプロファイルのファイルパスを指定します。
	特別な名前"auto"が指定された場合、ビルドの各メインパッケージについて、
	そのパッケージのディレクトリに"default.pgo"という名前のファイルが存在する場合、
	goコマンドはそれを選択し、それをメインパッケージの（トランジティブな）依存関係に適用します
	（他のパッケージには影響しません）。特別な名前"off"はPGOをオフにします。デフォルトは"auto"です。
-pkgdir dir
	通常の場所ではなく、dirからすべてのパッケージをインストールしてロードします。
	例えば、非標準の設定でビルドする場合、生成されたパッケージを別の場所に保持するために-pkgdirを使用します。
-tags tag,list
	ビルド中に満足させるための追加のビルドタグのカンマ区切りリスト。
	ビルドタグについての詳細は'go help buildconstraint'を参照してください。
	（Goの早いバージョンではスペース区切りのリストを使用していましたが、その形式は非推奨ですがまだ認識されます。）
-trimpath
	結果の実行可能ファイルからすべてのファイルシステムパスを削除します。
	絶対ファイルシステムパスの代わりに、記録されたファイル名はモジュールパス@バージョン（モジュールを使用する場合）で始まるか、
	またはプレーンなインポートパス（標準ライブラリ、またはGOPATHを使用する場合）で始まります。
-toolexec 'cmd args'
	vetやasmのようなツールチェーンプログラムを起動するために使用するプログラム。
	例えば、asmを実行する代わりに、goコマンドは'cmd args /path/to/asm <arguments for asm>'を実行します。
	TOOLEXEC_IMPORTPATH環境変数が設定され、ビルドされているパッケージの'go list -f {{.ImportPath}}'に一致します。

-asmflags、-gccgoflags、-gcflags、および-ldflagsフラグは、 ビルド中に基礎となるツールに渡すためのスペースで区切られた引数のリストを受け入れます。 リストの要素にスペースを埋め込むには、それをシングルクォートまたはダブルクォートで囲みます。 引数リストは、パッケージパターンと等号によって先行することができ、 それはその引数リストの使用を、そのパターンに一致するパッケージのビルドに制限します （パッケージパターンの説明については'go help packages'を参照してください）。 パターンがない場合、引数リストはコマンドライン上で名前が付けられたパッケージにのみ適用されます。 フラグは、異なるパッケージのセットに対して異なる引数を指定するために、 異なるパターンで繰り返すことができます。 パッケージが複数のフラグで与えられたパターンに一致する場合、 コマンドライン上で最新の一致が勝ちます。 例えば、'go build -gcflags=-S fmt'は、パッケージfmtのみの逆アセンブルを出力しますが、 'go build -gcflags=all=-S fmt'は、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フラグ] [buildフラグ] [パッケージ]

Cleanはパッケージソースディレクトリからオブジェクトファイルを削除します。 goコマンドはほとんどのオブジェクトを一時ディレクトリでビルドするため、 go cleanは主に他のツールによって残されたオブジェクトファイルや、 手動でのgo buildの呼び出しによって残されたオブジェクトファイルを対象としています。

パッケージ引数が与えられた場合、または-iまたは-rフラグが設定されている場合、 cleanはインポートパスに対応する各ソースディレクトリから以下のファイルを削除します:

_obj/            Makefilesから残された古いオブジェクトディレクトリ
_test/           Makefilesから残された古いテストディレクトリ
_testmain.go     Makefilesから残された古いgotestファイル
test.out         Makefilesから残された古いテストログ
build.out        Makefilesから残された古いテストログ
*.[568ao]        Makefilesから残されたオブジェクトファイル

DIR(.exe)        go buildから
DIR.test(.exe)   go test -cから
MAINFILE(.exe)   go build MAINFILE.goから
*.so             SWIGから

リストでは、DIRはディレクトリの最終パス要素を表し、 MAINFILEはパッケージをビルドする際に含まれないディレクトリ内の任意のGoソースファイルのベース名を表します。

-iフラグは、cleanに対応するインストール済みのアーカイブまたはバイナリ（'go install'が作成するもの）を削除するように指示します。

-nフラグは、cleanが実行する削除コマンドを表示するが、それらを実行しないようにします。

-rフラグは、cleanをインポートパスで指定されたパッケージのすべての依存関係に再帰的に適用するようにします。

-xフラグは、cleanがそれを実行するときに削除コマンドを表示するようにします。

-cacheフラグは、cleanがgoビルドキャッシュ全体を削除するようにします。

-testcacheフラグは、cleanがgoビルドキャッシュ内のすべてのテスト結果を期限切れにするようにします。

-modcacheフラグは、cleanがモジュールダウンロードキャッシュ全体、バージョン付き依存関係の展開されたソースコードを含むものを削除するようにします。

-fuzzcacheフラグは、cleanがGoビルドキャッシュに保存されたファズテスト用のファイルを削除するようにします。ファジングエンジンはコードカバレッジを拡大するファイルをキャッシュするため、それらを削除すると、同じカバレッジを提供する新しい入力が見つかるまでのファジングが効果的でなくなる可能性があります。これらのファイルはtestdataディレクトリに保存されたものとは異なり、cleanはそれらのファイルを削除しません。

ビルドフラグについての詳細は、'go help build'を参照してください。

パッケージの指定についての詳細は、'go help packages'を参照してください。

パッケージまたはシンボルのドキュメンテーションを表示する

使用法:

go doc [docフラグ] [パッケージ|[パッケージ.]シンボル[.メソッドまたはフィールド]]

Docは、その引数で識別される項目（パッケージ、const、func、type、var、method、またはstruct field）に関連付けられた ドキュメンテーションコメントを印刷し、その項目の"下"の各第一レベル項目（パッケージの場合はパッケージレベルの宣言、 typeの場合はメソッドなど）の1行の要約を続けて印刷します。

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>

引数によって一致したこのリストの最初の項目が、そのドキュメンテーションが印刷されるものです。 （以下の例を参照してください。）ただし、引数が大文字で始まる場合、それは現在のディレクトリのシンボルまたはメソッドを識別するものとみなされます。

パッケージの場合、スキャンの順序は、幅優先順序で辞書順に決定されます。 つまり、提示されるパッケージは、検索に一致し、ルートに最も近く、階層のそのレベルで辞書順に最初のものです。 GOROOTツリーは、常にGOPATHの前に全体がスキャンされます。

パッケージが指定されていないか一致しない場合、現在のディレクトリのパッケージが選択されます。 したがって、"go doc Foo"は、現在のパッケージのシンボルFooのドキュメンテーションを表示します。

パッケージパスは、修飾されたパスまたはパスの適切なサフィックスでなければなりません。 goツールの通常のパッケージメカニズムは適用されません：パッケージパス要素のような.や...はgo docによって実装されていません。

2つの引数で実行された場合、最初の引数はパッケージパス（完全なパスまたはサフィックス）であり、 2つ目はシンボル、またはメソッドまたは構造体フィールドを持つシンボルです：

go doc <pkg> <sym>[.<methodOrField>]

すべての形式で、シンボルをマッチングするとき、引数の小文字はどちらのケースでも一致しますが、大文字は正確に一致します。 これは、異なるシンボルが異なるケースを持つ場合、パッケージ内で小文字の引数の複数のマッチがある可能性があることを意味します。 これが発生した場合、すべてのマッチのドキュメンテーションが印刷されます。

例：

go doc
	現在のパッケージのドキュメンテーションを表示します。
go doc Foo
	現在のパッケージのFooに関するドキュメンテーションを表示します。
	(Fooは大文字で始まるため、パッケージパスと一致することはありません。)
go doc encoding/json
	encoding/jsonパッケージのドキュメンテーションを表示します。
go doc json
	encoding/jsonの省略形です。
go doc json.Number (または go doc json.number)
	json.Numberのドキュメンテーションとメソッドの概要を表示します。
go doc json.Number.Int64 (または go doc json.number.int64)
	json.NumberのInt64メソッドのドキュメンテーションを表示します。
go doc cmd/doc
	docコマンドのパッケージドキュメンテーションを表示します。
go doc -cmd cmd/doc
	docコマンド内のパッケージドキュメンテーションとエクスポートされたシンボルを表示します。
go doc template.new
	html/templateのNew関数のドキュメンテーションを表示します。
	(html/templateは辞書順でtext/templateの前に来ます)
go doc text/template.new # 引数が一つ
	text/templateのNew関数のドキュメンテーションを表示します。
go doc text/template new # 引数が二つ
	text/templateのNew関数のドキュメンテーションを表示します。

少なくとも現在のツリーでは、これらの呼び出しはすべてjson.DecoderのDecodeメソッドの ドキュメンテーションを印刷します：

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）を通常のパッケージとして扱います。
	それ以外の場合、パッケージmainのエクスポートされたシンボルは、
	パッケージのトップレベルのドキュメンテーションを表示するときに隠されます。
-short
	各シンボルの一行表現を表示します。
-src
	シンボルの完全なソースコードを表示します。これにより、
	その宣言と定義の完全なGoソースが表示されます。例えば、関数の定義（本体を含む）、
	型の宣言、または囲むconstブロックなどです。そのため、出力にはエクスポートされていない詳細が含まれる可能性があります。
-u
	エクスポートされたシンボル、メソッド、フィールドだけでなく、エクスポートされていないもののドキュメンテーションも表示します。

Go環境情報を表示する

使用法:

go env [-json] [-u] [-w] [var ...]

EnvはGo環境情報を表示します。

デフォルトでは、envは情報をシェルスクリプトとして表示します （Windowsでは、バッチファイル）。一つ以上の変数名が引数として 与えられた場合、envは各名前付き変数の値をそれぞれの行に表示します。

-jsonフラグは、環境をシェルスクリプトではなくJSON形式で表示します。

-uフラグは一つ以上の引数を必要とし、指定された環境変数のデフォルト設定を解除します。 これは、'go env -w'で設定されている場合に適用されます。

-wフラグは、形式がNAME=VALUEの一つ以上の引数を必要とし、指定された環境変数のデフォルト設定を 与えられた値に変更します。

環境変数についての詳細は、'go help environment'を参照してください。

新しいAPIを使用するようにパッケージを更新する

使用法:

go fix [-fix list] [packages]

Fixは、インポートパスで指定されたパッケージにGo fixコマンドを実行します。

-fixフラグは、実行する修正のカンマ区切りのリストを設定します。 デフォルトはすべての既知の修正です。 (その値は 'go tool fix -r'に渡されます。)

fixについての詳細は、'go doc cmd/fix'を参照してください。 パッケージの指定についての詳細は、'go help packages'を参照してください。

他のオプションでfixを実行するには、'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フラグはコマンドを実行するときにそれを出力します。

-modフラグの値は、どのモジュールダウンロードモードを使用するかを設定します：readonlyまたはvendor。 詳細は 'go help modules' を参照してください。

特定のオプションでgofmtを実行するには、gofmt自体を実行します。

参照してください: go fix, go vet.

ソースを処理してGoファイルを生成する

使用法:

go generate [-run regexp] [-n] [-v] [-x] [build flags] [file.go... | packages]

Generateは、既存のファイル内のディレクティブによって記述されたコマンドを実行します。 これらのコマンドは任意のプロセスを実行できますが、目的はGoソースファイルを作成または更新することです。

Go generateは、go build、go testなどによって自動的には実行されません。 明示的に実行する必要があります。

Go generateは、ファイルをスキャンしてディレクティブを探します。これらは、 以下の形式の行です。

//go:generate command argument...

(注意: 先頭にスペースはなく、"//go"の中にもスペースはありません) ここで、command はローカルで実行できる実行可能ファイルに対応する、実行するジェネレータです。 それはシェルパス内に存在する必要があります（gofmt）、完全に修飾されたパスである必要があります (/usr/you/bin/mytool)、または以下で説明するコマンドエイリアスである必要があります。

go generateはファイルを解析しないことに注意してください。そのため、コメントや 複数行の文字列の中にあるディレクティブのように見える行は、ディレクティブとして扱われます。

ディレクティブへの引数は、スペースで区切られたトークンまたはダブルクォートで囲まれた 文字列で、それらはジェネレータに個別の引数として渡されます。

引用符で囲まれた文字列はGoの構文を使用し、実行前に評価されます。引用符で囲まれた 文字列はジェネレータへの単一の引数として現れます。

コードが生成されることを人間とマシンツールに伝えるために、生成されたソースには、 以下の正規表現（Goの構文）に一致する行が存在するべきです：

^// Code generated .* DO NOT EDIT\.$

この行は、ファイル内の最初の非コメント、非空白の テキストの前に現れなければなりません。

Go generateは、ジェネレータを実行するときにいくつかの変数を設定します：

$GOARCH
	実行アーキテクチャ（arm、amd64など）
$GOOS
	実行オペレーティングシステム（linux、windowsなど）
$GOFILE
	ファイルのベース名。
$GOLINE
	ソースファイル内のディレクティブの行番号。
$GOPACKAGE
	ディレクティブを含むファイルのパッケージ名。
$GOROOT
	ジェネレータを起動した 'go' コマンドの GOROOT ディレクトリ。
	これにはGoツールチェーンと標準ライブラリが含まれます。
$DOLLAR
	ドル記号。
$PATH
	親プロセスの $PATH。$GOROOT/bin が
	先頭に配置されます。これにより、'go' コマンドを実行するジェネレータは
	親の 'go generate' コマンドと同じ 'go' を使用します。

変数の置換と引用文字列の評価以外に、コマンドライン上で "globbing"のような特別な処理は行われません。

コマンドを実行する前の最後のステップとして、$GOFILEや $HOMEなど、英数字の名前を持つ環境変数の呼び出しが、 コマンドライン全体で展開されます。変数の展開の構文は すべてのオペレーティングシステムで$NAMEです。評価の 順序により、変数は引用文字列の中でも展開されます。 変数NAMEが設定されていない場合、$NAMEは空の文字列に 展開されます。

以下の形式のディレクティブ

//go:generate -command xxx args...

は、このソースファイルの残りの部分についてのみ、文字列xxxが引数によって 識別されるコマンドを表すことを指定します。これはエイリアスを作成したり、 複数の単語を持つジェネレータを処理したりするために使用できます。 例えば、

//go:generate -command foo go tool foo

は、コマンド "foo" がジェネレータ "go tool foo" を表すことを指定します。

Generateは、コマンドラインで与えられた順序でパッケージを処理します、 一度に一つずつ。コマンドラインが単一のディレクトリからの.goファイルを リストしている場合、それらは単一のパッケージとして扱われます。パッケージ内では、 generateはパッケージ内のソースファイルをファイル名順に一つずつ処理します。 ソースファイル内では、generateはファイル内に現れる順序でジェネレータを実行します、 一度に一つずつ。go generateツールはまた、ビルドタグ "generate" を設定するので、 ファイルはgo generateによって調査されるが、ビルド中には無視されます。

コードが無効なパッケージの場合、generateは有効なパッケージ節を持つソースファイルのみを処理します。

任意のジェネレータがエラー終了ステータスを返すと、"go generate"はそのパッケージの すべてのさらなる処理をスキップします。

ジェネレータはパッケージのソースディレクトリで実行されます。

Go generateは2つの特定のフラグを受け入れます：

-run=""
	非空の場合、フルオリジナルソーステキスト（末尾のスペースと
	最終改行を除く）が表現に一致するディレクティブを選択するための
	正規表現を指定します。

-skip=""
	非空の場合、フルオリジナルソーステキスト（末尾のスペースと
	最終改行を除く）が表現に一致するディレクティブを抑制するための
	正規表現を指定します。ディレクティブが-runと-skipの両方の引数に
	一致する場合、それはスキップされます。

また、-v、-n、および-xを含む標準のビルドフラグも受け入れます。 -vフラグは、処理されるパッケージとファイルの名前を出力します。 -nフラグは実行されるコマンドを出力します。 -xフラグはコマンドを実行するときにそれを出力します。

ビルドフラグの詳細については、'go help build'を参照してください。

パッケージの指定についての詳細は、'go help packages'を参照してください。

現在のモジュールに依存関係を追加し、それらをインストールする

使用法:

go get [-t] [-u] [-v] [build flags] [packages]

Getは、コマンドライン引数を特定のモジュールバージョンのパッケージに解決し、 go.modを更新してそれらのバージョンを要求し、ソースコードをモジュールキャッシュにダウンロードします。

パッケージの依存関係を追加したり、最新バージョンにアップグレードするには：

go get example.com/pkg

パッケージを特定のバージョンにアップグレードまたはダウングレードするには：

go get example.com/pkg@v1.2.3

モジュールへの依存関係を削除し、それを必要とするモジュールをダウングレードするには：

go get example.com/mod@none

最小必要Goバージョンを最新リリースのGoバージョンにアップグレードするには：

go get go@latest

Goツールチェーンを現在のGoツールチェーンの最新パッチリリースにアップグレードするには：

go get toolchain@patch

詳細は https://golang.org/ref/mod#go-get を参照してください。

Goの初期のバージョンでは、'go get'はパッケージのビルドとインストールに使用されていました。 現在では、'go get'はgo.mod内の依存関係の調整に専用化されています。代わりに'go install' を使用してコマンドをビルドおよびインストールできます。バージョンが指定されている場合、 'go install'はモジュール対応モードで実行され、現在のディレクトリのgo.modファイルは無視されます。 例えば：

go install example.com/pkg@v1.2.3
go install example.com/pkg@latest

詳細は 'go help install' または https://golang.org/ref/mod#go-install を参照してください。

'go get'は以下のフラグを受け入れます。

-tフラグは、getにコマンドラインで指定されたパッケージのテストをビルドするために必要なモジュールを考慮するよう指示します。

-uフラグは、getにコマンドラインで指定されたパッケージの依存関係を提供するモジュールを更新し、利用可能な場合は新しいマイナーリリースまたはパッチリリースを使用するよう指示します。

-u=patchフラグ（-u patchではない）もまた、getに依存関係を更新するよう指示しますが、デフォルトをパッチリリースを選択するように変更します。

-tフラグと-uフラグが一緒に使用されると、getはテスト依存関係も更新します。

-xフラグは、実行されるコマンドを出力します。これは、モジュールが直接リポジトリからダウンロードされるときにバージョン管理コマンドをデバッグするのに便利です。

モジュールについての詳細は、https://golang.org/ref/mod を参照してください。

'go get'を使用して最小のGoバージョンと推奨されるGoツールチェーンを更新する方法についての詳細は、https://go.dev/doc/toolchain を参照してください。

パッケージの指定についての詳細は、'go help packages'を参照してください。

このテキストは、ソースコードと依存関係の管理にモジュールを使用してgetの動作を説明しています。代わりにgoコマンドがGOPATHモードで実行されている場合、getのフラグと効果の詳細が変わり、'go help get'も変わります。'go help gopath-get'を参照してください。

参照してください: go build, go install, go clean, go mod.

パッケージと依存関係をコンパイルしてインストールする

使用法:

go install [build flags] [packages]

Installは、インポートパスで指定されたパッケージをコンパイルしてインストールします。

実行可能ファイルは、GOBIN環境変数で指定されたディレクトリにインストールされます。 これは、GOPATH環境変数が設定されていない場合、デフォルトで$GOPATH/binまたは$HOME/go/binになります。 $GOROOT内の実行可能ファイルは、$GOBINではなく$GOROOT/binまたは$GOTOOLDIRにインストールされます。

引数にバージョン接尾辞（@latestや@v1.0.0のような）がある場合、"go install"は モジュール対応モードでパッケージをビルドし、現在のディレクトリや親ディレクトリにある go.modファイルを無視します。これは、メインモジュールの依存関係に影響を与えずに 実行可能ファイルをインストールするのに便利です。 ビルドで使用されるモジュールのバージョンについての曖昧性を排除するために、 引数は以下の制約を満たさなければなりません：

- 引数はパッケージパスまたはパッケージパターン（"..."ワイルドカード付き）でなければなりません。 標準パッケージ（fmtのような）、メタパターン（std、cmd、all）、または相対または絶対ファイルパスであってはなりません。

- すべての引数は同じバージョン接尾辞を持たなければなりません。同じバージョンを参照していても、異なるクエリは許可されません。

- すべての引数は、同じバージョンの同じモジュール内のパッケージを参照しなければなりません。

- パッケージパス引数はmainパッケージを参照しなければなりません。パターン引数はmainパッケージのみに一致します。

- "main"モジュールと見なされるモジュールはありません。コマンドラインで指定されたパッケージを含むモジュールにgo.modファイルがある場合、それはmainモジュールであるかのように解釈されるのと異なる方法で解釈されるような指示（replaceとexclude）を含んではなりません。モジュールは自身のより高いバージョンを要求してはなりません。

- ベンダーディレクトリはどのモジュールでも使用されません。（ベンダーディレクトリは'go install'によってダウンロードされるモジュールのzipファイルに含まれません。）

引数にバージョン接尾辞がない場合、"go install"はGO111MODULE環境変数とgo.modファイルの存在に応じて、 モジュール対応モードまたはGOPATHモードで実行される可能性があります。詳細は'go help modules'を参照してください。 モジュール対応モードが有効になっている場合、"go install"はメインモジュールのコンテキストで実行されます。

モジュール対応モードが無効になっている場合、非メインパッケージはディレクトリ$GOPATH/pkg/$GOOS_$GOARCHにインストールされます。 モジュール対応モードが有効になっている場合、非メインパッケージはビルドされてキャッシュされますが、インストールされません。

Go 1.20より前では、標準ライブラリは$GOROOT/pkg/$GOOS_$GOARCHにインストールされていました。 Go 1.20からは、標準ライブラリはビルドされてキャッシュされますが、インストールされません。 GODEBUG=installgoroot=allを設定すると、$GOROOT/pkg/$GOOS_$GOARCHの使用が復元されます。

ビルドフラグについての詳細は、'go help build'を参照してください。

パッケージの指定についての詳細は、'go help packages'を参照してください。

参照してください: go build, go get, go clean.

パッケージまたはモジュールをリストアップする

使用法:

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

Listは、指定されたパッケージを一行に一つずつリストアップします。 最も一般的に使用されるフラグは-fと-jsonで、これらは各パッケージに対して出力される形式を制御します。 他のlistフラグは、以下で説明されているように、より具体的な詳細を制御します。

デフォルトの出力はパッケージのインポートパスを表示します:

bytes
encoding/json
github.com/gorilla/mux
golang.org/x/net/html

-fフラグは、リストの代替形式を指定します。これはパッケージテンプレートの構文を使用します。 デフォルトの出力は-f '{{.ImportPath}}'と同等です。テンプレートに渡される構造体は:

type Package struct {
    Dir            string   // パッケージソースが含まれるディレクトリ
    ImportPath     string   // dir内のパッケージのインポートパス
    ImportComment  string   // パッケージステートメントのインポートコメントのパス
    Name           string   // パッケージ名
    Doc            string   // パッケージのドキュメンテーション文字列
    Target         string   // インストールパス
    Shlib          string   // このパッケージを含む共有ライブラリ（-linksharedを使用するときのみ設定）
    Goroot         bool     // このパッケージはGo rootにありますか？
    Standard       bool     // このパッケージは標準のGoライブラリの一部ですか？
    Stale          bool     // 'go install'はこのパッケージに対して何かを行いますか？
    StaleReason    string   // Stale==trueの説明
    Root           string   // このパッケージを含むGo rootまたはGo path dir
    ConflictDir    string   // このディレクトリは$GOPATH内のDirをシャドウします
    BinaryOnly     bool     // バイナリのみのパッケージ（もはやサポートされていません）
    ForTest        string   // パッケージは名前付きテストでのみ使用されます
    Export         string   // エクスポートデータを含むファイル（-exportを使用するとき）
    BuildID        string   // コンパイルされたパッケージのビルドID（-exportを使用するとき）
    Module         *Module  // パッケージの含まれるモジュールに関する情報、もしあれば（nilにできます）
    Match          []string // このパッケージに一致するコマンドラインパターン
    DepOnly        bool     // パッケージは依存関係のみで、明示的にリストされていません
    DefaultGODEBUG string   // メインパッケージのデフォルトのGODEBUG設定

    // ソースファイル
    GoFiles           []string   // .goソースファイル（CgoFiles、TestGoFiles、XTestGoFilesを除く）
    CgoFiles          []string   // "C"をインポートする.goソースファイル
    CompiledGoFiles   []string   // コンパイラに提示される.goファイル（-compiledを使用するとき）
    IgnoredGoFiles    []string   // ビルド制約により無視される.goソースファイル
    IgnoredOtherFiles []string // ビルド制約により無視される非.goソースファイル
    CFiles            []string   // .cソースファイル
    CXXFiles          []string   // .cc、.cxxおよび.cppソースファイル
    MFiles            []string   // .mソースファイル
    HFiles            []string   // .h、.hh、.hppおよび.hxxソースファイル
    FFiles            []string   // .f、.F、.forおよび.f90 Fortranソースファイル
    SFiles            []string   // .sソースファイル
    SwigFiles         []string   // .swigファイル
    SwigCXXFiles      []string   // .swigcxxファイル
    SysoFiles         []string   // アーカイブに追加する.sysoオブジェクトファイル
    TestGoFiles       []string   // パッケージ内の_test.goファイル
    XTestGoFiles      []string   // パッケージ外の_test.goファイル

    // 埋め込みファイル
    EmbedPatterns      []string // //go:embed パターン
    EmbedFiles         []string // EmbedPatternsにマッチしたファイル
    TestEmbedPatterns  []string // TestGoFiles内の//go:embed パターン
    TestEmbedFiles     []string // TestEmbedPatternsにマッチしたファイル
    XTestEmbedPatterns []string // XTestGoFiles内の//go:embed パターン
    XTestEmbedFiles    []string // XTestEmbedPatternsにマッチしたファイル

    // Cgoのディレクティブ
    CgoCFLAGS    []string // cgo: Cコンパイラのフラグ
    CgoCPPFLAGS  []string // cgo: Cプリプロセッサのフラグ
    CgoCXXFLAGS  []string // cgo: C++コンパイラのフラグ
    CgoFFLAGS    []string // cgo: Fortranコンパイラのフラグ
    CgoLDFLAGS   []string // cgo: リンカーのフラグ
    CgoPkgConfig []string // cgo: pkg-configの名前

    // 依存関係情報
    Imports      []string          // このパッケージが使用するインポートパス
    ImportMap    map[string]string // ソースインポートからImportPathへのマップ（同一エントリーは省略）
    Deps         []string          // すべての（再帰的に）インポートされた依存関係
    TestImports  []string          // TestGoFilesからのインポート
    XTestImports []string          // XTestGoFilesからのインポート

    // エラー情報
    Incomplete bool            // このパッケージまたは依存関係にエラーがあります
    Error      *PackageError   // パッケージの読み込みエラー
    DepsErrors []*PackageError // 依存関係の読み込みエラー
}

ベンダーディレクトリに格納されたパッケージは、ベンダーディレクトリへのパスを含むImportPathを報告します （例えば、"p"の代わりに"d/vendor/p"）。 これにより、ImportPathはパッケージの特定のコピーを一意に識別します。 Imports、Deps、TestImports、およびXTestImportsのリストもこれらの 拡張されたインポートパスを含みます。ベンダリングについての詳細は、golang.org/s/go15vendorを参照してください。

エラー情報（存在する場合）は以下の通りです

type PackageError struct {
    ImportStack   []string // コマンドラインで指定されたパッケージからこのパッケージへの最短パス
    Pos           string   // エラーの位置（存在する場合、file:line:col）
    Err           string   // エラーそのもの
}

モジュール情報はModule構造体で、以下のlist -mの議論で定義されています。

テンプレート関数 "join" は strings.Join を呼び出します。

テンプレート関数 "context" はビルドコンテキストを返します。これは以下のように定義されています：

type Context struct {
    GOARCH        string   // ターゲットアーキテクチャ
    GOOS          string   // ターゲットオペレーティングシステム
    GOROOT        string   // Goのルート
    GOPATH        string   // Goのパス
    CgoEnabled    bool     // cgoが使用可能かどうか
    UseAllFiles   bool     // //go:build行、ファイル名に関係なくファイルを使用する
    Compiler      string   // ターゲットパスを計算する際に想定するコンパイラ
    BuildTags     []string // //go:build行でマッチさせるビルド制約
    ToolTags      []string // ツールチェーン固有のビルド制約
    ReleaseTags   []string // 現在のリリースと互換性のあるリリース
    InstallSuffix string   // インストールディレクトリの名前に使用する接尾辞
}

これらのフィールドの意味についての詳細は、go/buildパッケージのContext型のドキュメンテーションを参照してください。

-jsonフラグは、パッケージデータをテンプレート形式ではなくJSON形式で出力するように指示します JSONフラグは、出力する必要のあるフィールド名のセットをカンマ区切りでオプションで提供できます。 その場合、それらの必要なフィールドは常にJSON出力に表示されますが、 JSON構造体の計算における作業を節約するために他のフィールドは省略されるかもしれません。

-compiledフラグは、listに対してCompiledGoFilesをコンパイラに提示されるGoソースファイルに設定するよう指示します。 通常、これはGoFilesにリストされたファイルを繰り返し、その後でCgoFilesとSwigFilesの処理によって生成されたGoコードも追加します。 Importsリストは、GoFilesとCompiledGoFilesの両方からのすべてのインポートの統合を含みます。

-depsフラグは、listに対して指定されたパッケージだけでなく、そのすべての依存関係も反復処理するよう指示します。 これは深さ優先の後順走査でそれらを訪問し、その結果、パッケージはそのすべての依存関係の後にのみリストされます。 コマンドラインで明示的にリストされていないパッケージは、DepOnlyフィールドがtrueに設定されます。

-eフラグは、見つけることができないか形式が正しくないパッケージ、つまりエラーパッケージの処理を変更します。 デフォルトでは、listコマンドは各エラーパッケージについて標準エラーにエラーを出力し、 通常の出力時にパッケージを考慮から省きます。 -eフラグを使用すると、listコマンドは標準エラーにエラーを出力せず、 代わりに通常の出力でエラーパッケージを処理します。 エラーパッケージは空でないImportPathとnilでないErrorフィールドを持ちます。 他の情報は欠落しているかもしれません（ゼロ化されているかもしれません）。

-exportフラグは、listに対してExportフィールドを指定されたパッケージの最新のエクスポート情報を含む ファイルの名前に設定するよう指示します。 また、BuildIDフィールドはコンパイルされたパッケージのビルドIDに設定されます。

-findフラグは、listに対して指定されたパッケージを特定するが、 その依存関係は解決しないように指示します：ImportsとDepsのリストは空になります。 -findフラグを使用すると、-deps、-test、および-exportコマンドは使用できません。

-testフラグを使用すると、listは指定されたパッケージだけでなく、 テストがあるパッケージのテストバイナリも報告します。これにより、 ソースコード分析ツールにテストバイナリがどのように構築されるかを正確に伝えます。 テストバイナリの報告されるインポートパスは、パッケージのインポートパスに ".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フラグを使用すると、listはパッケージではなくモジュールをリストします。

モジュールをリストするとき、-fフラグはまだフォーマットテンプレートを指定しますが、 今度はModule構造体に適用されます：

type Module struct {
    Path       string        // モジュールパス
    Query      string        // このバージョンに対応するバージョンクエリ
    Version    string        // モジュールバージョン
    Versions   []string      // 利用可能なモジュールバージョン
    Replace    *Module       // このモジュールによって置き換えられます
    Time       *time.Time    // バージョンが作成された時間
    Update     *Module       // 利用可能な更新（-uとともに）
    Main       bool          // これはメインモジュールですか？
    Indirect   bool          // モジュールはメインモジュールによって間接的にのみ必要とされます
    Dir        string        // ファイルのローカルコピーを保持するディレクトリ（あれば）
    GoMod      string        // モジュールを記述するgo.modファイルへのパス（あれば）
    GoVersion  string        // モジュールで使用されるgoのバージョン
    Retracted  []string      // 撤回情報（あれば）（-retractedまたは-uとともに）
    Deprecated string        // 非推奨メッセージ（あれば）（-uとともに）
    Error      *ModuleError  // モジュールの読み込みエラー
    Origin     any           // モジュールの出所
    Reuse      bool          // 古いモジュール情報の再利用は安全です
}

type ModuleError struct {
    Err string // エラーそのもの
}

GoModファイルは、モジュールがモジュールキャッシュにある場合、 または-modfileフラグが使用されている場合、モジュールディレクトリの外部にあるかもしれません。

デフォルトの出力は、モジュールパスを印刷し、 その後、バージョンと置換（あれば）についての情報を印刷することです。 例えば、'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フィールドは 置換モジュールを説明し、そのDirフィールドは、存在する場合、 置換のソースコードに設定されます。（つまり、Replaceが非nilの場合、 DirはReplace.Dirに設定され、置換されたソースコードにはアクセスできません。）

-uフラグは利用可能なアップグレードに関する情報を追加します。 特定のモジュールの最新バージョンが現在のものより新しい場合、 list -uはモジュールのUpdateフィールドを新しいモジュールに関する情報に設定します。 list -uは、現在のバージョンが撤回されている場合、モジュールのRetractedフィールドも設定します。 モジュールのStringメソッドは、現在のバージョンの後に新しいバージョンを括弧でフォーマットすることで 利用可能なアップグレードを示します。 バージョンが撤回されている場合、文字列"(retracted)"がそれに続きます。 例えば、'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 (retracted) [v0.1.2]

(ツールの場合、'go list -m -u -json all'の方が解析しやすいかもしれません。)

-versionsフラグを使用すると、listはModuleのVersionsフィールドを そのモジュールのすべての既知のバージョンのリストに設定します。これらは セマンティックバージョニングに従って、最初から最新の順に並べられます。このフラグはまた、 デフォルトの出力形式を変更して、モジュールパスに続いてスペースで区切られたバージョンリストを表示します。

-retractedフラグを使用すると、listは撤回されたモジュールバージョンに関する情報を報告します。 -retractedが-fまたは-jsonと一緒に使用されると、Retractedフィールドは、 バージョンがなぜ撤回されたかを説明する文字列に設定されます。 この文字列は、モジュールのgo.modファイルのretractディレクティブのコメントから取得されます。 -retractedが-versionsと一緒に使用されると、撤回されたバージョンと撤回されていないバージョンが一緒にリストされます。 -retractedフラグは、-mの有無に関係なく使用できます。

list -mへの引数は、パッケージではなくモジュールのリストとして解釈されます。 メインモジュールは、現在のディレクトリを含むモジュールです。 アクティブなモジュールは、メインモジュールとその依存関係です。 引数がない場合、list -mはメインモジュールを表示します。 引数がある場合、list -mは引数で指定されたモジュールを表示します。 アクティブなモジュールは、そのモジュールパスで指定できます。 特別なパターン"all"は、すべてのアクティブなモジュールを指定します。最初にメインモジュール、 その後モジュールパスでソートされた依存関係。 "..."を含むパターンは、モジュールパスがパターンに一致するアクティブなモジュールを指定します。 path@versionの形式のクエリは、そのクエリの結果を指定します。 これはアクティブなモジュールに限定されません。 モジュールクエリの詳細については、'go help modules'を参照してください。

テンプレート関数 "module" は、モジュールパスまたはクエリである必要がある 単一の文字列引数を取り、指定されたモジュールをModule構造体として返します。 エラーが発生した場合、結果は非nilのErrorフィールドを持つModule構造体になります。

-mを使用しているとき、-reuse=old.jsonフラグは、以前の'go list -m -json'の実行結果を 含むファイルの名前を受け入れます。この実行は、同じセットの修飾フラグ（-u、-retracted、-versionsなど）を使用します。 goコマンドは、このファイルを使用して、モジュールが前回の呼び出し以降に変更されていないことを判断し、 それについての情報の再ダウンロードを避けることができます。 再ダウンロードされないモジュールは、新しい出力でReuseフィールドをtrueに設定することでマークされます。 通常、モジュールキャッシュはこの種の再利用を自動的に提供します。しかし、モジュールキャッシュを保持しないシステムでは、 -reuseフラグが役立つことがあります。

ビルドフラグについての詳細は、'go help build'を参照してください。

パッケージの指定についての詳細は、'go help packages'を参照してください。

モジュールについての詳細は、https://golang.org/ref/modを参照してください。

モジュールのメンテナンス

Go modはモジュールの操作へのアクセスを提供します。

モジュールのサポートは、'go mod'だけでなく、すべてのgoコマンドに組み込まれていることに注意してください。 例えば、日々の依存関係の追加、削除、アップグレード、ダウングレードは、'go get'を使用して行うべきです。 モジュール機能の概要については、'go help modules'を参照してください。

使用法：

go mod <command> [arguments]

コマンドは次のとおりです：

download    モジュールをローカルキャッシュにダウンロード
edit        ツールやスクリプトからgo.modを編集
graph       モジュール要件グラフを印刷
init        現在のディレクトリに新しいモジュールを初期化
tidy        不足しているモジュールを追加し、使用されていないモジュールを削除
vendor      依存関係のベンダーコピーを作成
verify      依存関係が期待した内容を持っていることを確認
why         パッケージやモジュールが必要な理由を説明

コマンドの詳細については、"go help mod <command>"を使用してください。

モジュールをローカルキャッシュにダウンロード

使用法：

go mod download [-x] [-json] [-reuse=old.json] [modules]

Downloadは指定されたモジュールをダウンロードします。これらは、メインモジュールの依存関係を選択するモジュールパターン またはpath@version形式のモジュールクエリになることができます。

引数がない場合、downloadはメインモジュール内のパッケージをビルドおよびテストするために必要なモジュールに適用されます： メインモジュールが'go 1.17'以上で明示的に必要とされるモジュール、または'go 1.16'以下であればすべての トランジティブに必要なモジュール。

goコマンドは、通常の実行中に必要に応じてモジュールを自動的にダウンロードします。 "go mod download"コマンドは、主にローカルキャッシュを事前に準備するため、 またはGoモジュールプロキシの答えを計算するために役立ちます。

デフォルトでは、downloadは標準出力に何も書き込みません。進行状況のメッセージやエラーを標準エラーに出力することがあります。

-jsonフラグを使用すると、downloadは標準出力にJSONオブジェクトのシーケンスを出力します。 これは、ダウンロードされた各モジュール（または失敗）を説明し、次のGo構造体に対応します：

type Module struct {
    Path     string // モジュールパス
    Query    string // このバージョンに対応するバージョンクエリ
    Version  string // モジュールバージョン
    Error    string // モジュールの読み込みエラー
    Info     string // キャッシュされた.infoファイルへの絶対パス
    GoMod    string // キャッシュされた.modファイルへの絶対パス
    Zip      string // キャッシュされた.zipファイルへの絶対パス
    Dir      string // キャッシュされたソースルートディレクトリへの絶対パス
    Sum      string // パス、バージョンのチェックサム（go.sum内）
    GoModSum string // go.modのチェックサム（go.sum内）
    Origin   any    // モジュールの出所
    Reuse    bool   // 古いモジュール情報の再利用は安全
}

-reuseフラグは、以前の'go mod download -json'の実行結果を含むファイルの名前を受け入れます。 goコマンドは、このファイルを使用して、モジュールが前回の呼び出し以降に変更されていないことを判断し、 それについての情報の再ダウンロードを避けることができます。再ダウンロードされないモジュールは、 新しい出力でReuseフィールドをtrueに設定することでマークされます。通常、モジュールキャッシュは この種の再利用を自動的に提供します。しかし、モジュールキャッシュを保持しないシステムでは、 -reuseフラグが役立つことがあります。

-xフラグを使用すると、downloadは実行するコマンドを出力します。

'go mod download'についての詳細は、https://golang.org/ref/mod#go-mod-download を参照してください。

バージョンクエリについての詳細は、https://golang.org/ref/mod#version-queries を参照してください。

ツールやスクリプトからgo.modを編集

使用法：

go mod edit [編集フラグ] [-fmt|-print|-json] [go.mod]

Editは、主にツールやスクリプトによる使用のためのgo.modの編集用コマンドラインインターフェースを提供します。 それはgo.modのみを読み取り、関与するモジュールについての情報を探しません。 デフォルトでは、editはメインモジュールのgo.modファイルを読み書きしますが、 編集フラグの後に異なるターゲットファイルを指定することができます。

編集フラグは、編集操作のシーケンスを指定します。

-fmtフラグは、他の変更を加えずにgo.modファイルを再フォーマットします。 この再フォーマットは、go.modファイルを使用または書き換える他の修正によっても暗示されます。 このフラグが必要な唯一の時間は、他のフラグが指定されていない場合、つまり 'go mod edit -fmt'のような場合です。

-moduleフラグは、モジュールのパスを変更します（go.modファイルのモジュール行）。

-require=path@versionと-droprequire=pathフラグは、 指定されたモジュールパスとバージョンに対する要求を追加し、削除します。 -requireはpath上の既存の要求をすべて上書きすることに注意してください。 これらのフラグは主に、モジュールグラフを理解するツールのためのものです。 ユーザーは'go get path@version'または'go get path@none'を好むべきです。 これらは、他のモジュールによって課される制約を満たすために必要な他のgo.modの調整も行います。

-exclude=path@versionと-dropexclude=path@versionフラグは、 指定されたモジュールパスとバージョンに対する除外を追加し、削除します。 -exclude=path@versionは、その除外が既に存在する場合、何も操作を行いません。

-replace=old[@v]=new[@v]フラグは、指定されたモジュールパスとバージョンのペアの置換を追加します。 old@vの@vが省略された場合、左側にバージョンがない置換が追加され、oldモジュールパスのすべてのバージョンに適用されます。 new@vの@vが省略された場合、新しいパスはモジュールパスではなく、ローカルのモジュールルートディレクトリであるべきです。 -replaceはold[@v]の冗長な置換をすべて上書きすることに注意してください。したがって、@vを省略すると、特定のバージョンの既存の置換が削除されます。

-dropreplace=old[@v]フラグは、指定されたモジュールパスとバージョンのペアの置換を削除します。 @vが省略された場合、左側にバージョンがない置換が削除されます。

-retract=versionと-dropretract=versionフラグは、指定されたバージョンに対する撤回を追加し、削除します。 バージョンは、"v1.2.3"のような単一のバージョンまたは"[v1.1.0,v1.1.9]"のような閉区間である可能性があります。 その撤回が既に存在する場合、-retract=versionは何も操作を行わないことに注意してください。

-require、-droprequire、-exclude、-dropexclude、-replace、 -dropreplace、-retract、および -dropretractの編集フラグは繰り返すことができ、 与えられた順序で変更が適用されます。

-go=versionフラグは、期待されるGo言語のバージョンを設定します。

-toolchain=nameフラグは、使用するGoツールチェーンを設定します。

-printフラグは、最終的なgo.modをテキスト形式で印刷し、go.modに戻す代わりにそれを印刷します。

-jsonフラグは、最終的なgo.modファイルをJSON形式で印刷し、go.modに戻す代わりにそれを印刷します。JSON出力は、これらのGo型に対応します：

type Module struct {
	Path    string
	Version string
}

type GoMod struct {
	Module    ModPath
	Go        string
	Toolchain string
	Require   []Require
	Exclude   []Module
	Replace   []Replace
	Retract   []Retract
}

type ModPath struct {
	Path       string
	Deprecated string
}

type Require struct {
	Path string
	Version string
	Indirect bool
}

type Replace struct {
	Old Module
	New Module
}

type Retract struct {
	Low       string
	High      string
	Rationale string
}

単一のバージョンを表すRetractエントリ（間隔ではない）は、 "Low"と"High"のフィールドが同じ値に設定されます。

Note that this only describes the go.mod file itself, not other modules referred to indirectly. For the full set of modules available to a build, use 'go list -m -json all'.

Edit also provides the -C, -n, and -x build flags.

See https://golang.org/ref/mod#go-mod-edit for more about 'go mod edit'.

モジュール要求グラフの印刷

使用法：

go mod graph [-go=version] [-x]

Graphは、モジュール要求グラフ（置換が適用された状態）をテキスト形式で印刷します。 出力の各行には、スペースで区切られた2つのフィールドがあります：モジュールとその要求の一つ。 各モジュールは、path@versionの形式の文字列として識別されますが、メインモジュールは@version接尾辞がありません。

-goフラグは、go.modファイルの'go'ディレクティブで示されるバージョンではなく、 指定されたGoバージョンによってロードされたモジュールグラフを報告するようにgraphに指示します。

-xフラグは、graphが実行するコマンドを印刷するようにgraphに指示します。

'go mod graph'についての詳細は、https://golang.org/ref/mod#go-mod-graph を参照してください。

現在のディレクトリで新しいモジュールを初期化

使用法：

go mod init [module-path]

Initは、新しいgo.modファイルを初期化し、現在のディレクトリに書き込むことで、 現在のディレクトリをルートとする新しいモジュールを作成します。go.modファイルはすでに存在していてはなりません。

Initは、新しいモジュールのモジュールパスを1つのオプション引数として受け入れます。もし モジュールパス引数が省略された場合、initは.goファイルのインポートコメント、 ベンダーツールの設定ファイル（Gopkg.lockのような）、そして現在のディレクトリ（GOPATH内であれば）を 使用してモジュールパスを推測しようとします。

ベンダーツールの設定ファイルが存在する場合、initはそれからモジュール要件をインポートしようとします。

'go mod init'についての詳細は、https://golang.org/ref/mod#go-mod-init を参照してください。

不足しているモジュールの追加と使用されていないモジュールの削除

使用法：

go mod tidy [-e] [-v] [-x] [-go=version] [-compat=version]

Tidyは、go.modがモジュール内のソースコードと一致することを確認します。 現在のモジュールのパッケージと依存関係をビルドするために必要なモジュールを追加し、 関連するパッケージを提供しない使用されていないモジュールを削除します。また、 go.sumに不足しているエントリを追加し、不必要なものを削除します。

-vフラグは、tidyが削除されたモジュールについての情報を標準エラーに印刷するようにします。

-eフラグは、パッケージのロード中にエラーが発生した場合でも、tidyが処理を続行しようとするようにします。

-goフラグは、tidyがgo.modファイル内の'go'ディレクティブを指定されたバージョンに更新するようにします。 これにより、go.modファイル内で明示的な要件として保持されるモジュール依存関係が変更される可能性があります。 （Goバージョン1.17以降は、遅延モジュールロードをサポートするためにより多くの要件を保持します。）

-compatフラグは、指定されたメジャーGoリリースからの'go'コマンドがモジュールグラフを正常にロードするために 必要な追加のチェックサムを保持し、そのバージョンの'go'コマンドが異なるモジュールバージョンからインポートされた パッケージをロードすると、tidyがエラーを出すようにします。デフォルトでは、tidyは-compatフラグがgo.modファイル内の 'go'ディレクティブによって示されるバージョンよりも前のバージョンに設定されているかのように動作します。

-xフラグは、tidyがdownloadが実行するコマンドを印刷するようにします。

'go mod tidy'についての詳細は、https://golang.org/ref/mod#go-mod-tidy を参照してください。

依存関係のベンダー版のコピーを作成

使用法：

go mod vendor [-e] [-v] [-o outdir]

Vendorは、メインモジュールのベンダーディレクトリをリセットして、 メインモジュールのすべてのパッケージをビルドおよびテストするために必要なすべてのパッケージを含めます。 ベンダー化されたパッケージのテストコードは含まれません。

-vフラグは、ベンダーがベンダー化されたモジュールとパッケージの名前を標準エラーに印刷するようにします。

-eフラグは、パッケージのロード中にエラーが発生した場合でも、ベンダーが処理を続行しようとするようにします。

-oフラグは、ベンダーが指定されたパスにベンダーディレクトリを作成するようにします。 "vendor"ではない。goコマンドはモジュールのルートディレクトリ内の"vendor"という名前のベンダーディレクトリのみを使用できるため、 このフラグは主に他のツールに有用です。

'go mod vendor'についての詳細は、https://golang.org/ref/mod#go-mod-vendor を参照してください。

依存関係が期待通りの内容であることを確認

使用法：

go mod verify

Verifyは、現在のモジュールの依存関係が、ローカルのダウンロード済みソースキャッシュに保存されているものが、 ダウンロードされてから変更されていないことを確認します。すべてのモジュールが変更されていない場合、 verifyは"all modules verified."を印刷します。それ以外の場合、どのモジュールが変更されたかを報告し、 'go mod'が非ゼロのステータスで終了する原因となります。

'go mod verify'についての詳細は、https://golang.org/ref/mod#go-mod-verify を参照してください。

パッケージまたはモジュールが必要な理由を説明

使用法：

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

Whyは、メインモジュールからリスト化された各パッケージへのインポートグラフの最短パスを表示します。 -mフラグが指定されている場合、whyは引数をモジュールのリストとして扱い、各モジュール内の任意のパッケージへのパスを見つけます。

デフォルトでは、whyは"go list all"によってマッチしたパッケージのグラフを問い合わせます。 これには、到達可能なパッケージのテストが含まれます。-vendorフラグを指定すると、whyは依存関係のテストを除外します。

出力は、コマンドライン上の各パッケージまたはモジュール名に対して、空行で区切られたスタンザのシーケンスです。 各スタンザは、ターゲットパッケージまたはモジュールを示す"# package"または"# module"のコメント行で始まります。 続く行は、インポートグラフを通じたパスを1行に1つのパッケージで示します。パッケージまたはモジュールがメインモジュールから参照されていない場合、 スタンザはその事実を示す単一の括弧付きノートを表示します。

例えば：

$ 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 mod why'についての詳細は、https://golang.org/ref/mod#go-mod-why を参照してください。

ワークスペースのメンテナンス

Workは、ワークスペースの操作へのアクセスを提供します。

ワークスペースのサポートは、'go work'だけでなく、他の多くのコマンドに組み込まれていることに注意してください。

Goのモジュールシステムについての情報は、'go help modules'を参照してください。ワークスペースはその一部です。

ワークスペースについての詳細なリファレンスは、https://go.dev/ref/mod#workspaces を参照してください。

ワークスペースについての入門チュートリアルは、https://go.dev/doc/tutorial/workspaces を参照してください。

ワークスペースは、"use"ディレクティブで一連のモジュールディレクトリを指定するgo.workファイルによって指定されます。 これらのモジュールは、ビルドや関連操作のためのルートモジュールとしてgoコマンドによって使用されます。 使用するモジュールを指定しないワークスペースは、ローカルモジュールからのビルドを行うためには使用できません。

go.workファイルは行指向です。各行は単一のディレクティブを保持し、 キーワードに続く引数で構成されます。例えば：

go 1.18

use ../foo/bar
use ./baz

replace example.com/foo v1.2.3 => example.com/bar v1.4.5

先頭のキーワードは、Goのインポートのように、隣接する行からブロックを作成するために要素化できます。

use (
  ../foo/bar
  ./baz
)

useディレクティブは、ワークスペースのメインモジュールのセットに含めるモジュールを指定します。 useディレクティブの引数は、モジュールのgo.modファイルが含まれるディレクトリです。

goディレクティブは、ファイルが書かれたGoのバージョンを指定します。将来的にワークスペースのセマンティクスに 変更がある可能性があり、このバージョンによって制御されるかもしれませんが、現時点では指定されたバージョンは 効果がありません。

replaceディレクティブは、go.modファイル内のreplaceディレクティブと同じ構文を持ち、go.modファイル内のreplaceよりも 優先されます。これは主に、異なるワークスペースモジュール内の競合するreplaceを上書きするために意図されています。

goコマンドがワークスペースモードで動作しているかどうかを判断するには、"go env GOWORK"コマンドを使用します。 これにより、使用されているワークスペースファイルが指定されます。

使用法：

go work <コマンド> [引数]

コマンドは以下の通りです：

edit        ツールやスクリプトからgo.workを編集
init        ワークスペースファイルを初期化
sync        ワークスペースのビルドリストをモジュールに同期
use         ワークスペースファイルにモジュールを追加

コマンドについての詳細な情報は "go help work <コマンド>" を使用してください。

ツールやスクリプトからgo.workを編集

使用法：

go work edit [編集フラグ] [go.work]

Editは、主にツールやスクリプトによる使用を目的とした、go.workの編集用のコマンドラインインターフェースを提供します。 それはgo.workのみを読み取り、関与するモジュールについての情報を検索しません。 ファイルが指定されていない場合、Editは現在のディレクトリとその親ディレクトリでgo.workファイルを探します。

編集フラグは一連の編集操作を指定します。

-fmtフラグは、他の変更を行わずにgo.workファイルを再フォーマットします。 この再フォーマットは、go.modファイルの使用や書き換えを伴う他の修正にも含まれます。 このフラグが必要な唯一の時期は、他のフラグが指定されていない場合、つまり 'go work edit -fmt' のような場合です。

-use=pathおよび-dropuse=pathフラグは、 go.workファイルのモジュールディレクトリのセットにuseディレクティブを追加および削除します。

-replace=old[@v]=new[@v]フラグは、指定された モジュールパスとバージョンのペアの置換を追加します。old@vの@vが省略された場合、 左側にバージョンがない置換が追加され、oldモジュールパスのすべてのバージョンに適用されます。 new@vの@vが省略された場合、新しいパスはモジュール パスではなく、ローカルのモジュールルートディレクトリであるべきです。 -replaceはold[@v]の冗長な置換を上書きすることに注意してください。 したがって、@vを省略すると、特定のバージョンの既存の置換が削除されます。

-dropreplace=old[@v]フラグは、指定された モジュールパスとバージョンのペアの置換を削除します。@vが省略された場合、 左側にバージョンがない置換が削除されます。

-use、-dropuse、-replace、および -dropreplaceの編集フラグは、 繰り返すことができ、与えられた順序で変更が適用されます。

-go=versionフラグは、期待されるGo言語のバージョンを設定します。

-toolchain=nameフラグは、使用するGoツールチェーンを設定します。

-printフラグは、最終的なgo.workをテキスト形式で印刷し、 go.modに書き戻す代わりに表示します。

-jsonフラグは、最終的なgo.workファイルをJSON形式で印刷し、 go.modに書き戻す代わりに表示します。JSON出力は以下のGo型に対応します：

type GoWork struct {
	Go        string
	Toolchain string
	Use       []Use
	Replace   []Replace
}

type Use struct {
	DiskPath   string
	ModulePath string
}

type Replace struct {
	Old Module
	New Module
}

type Module struct {
	Path    string
	Version string
}

詳細情報については、https://go.dev/ref/mod#workspaces のワークスペースリファレンスを参照してください。

ワークスペースファイルの初期化

使用法：

go work init [moddirs]

Initは、新しいgo.workファイルを現在のディレクトリに初期化し、書き込むことで、 現在のディレクトリに新しいワークスペースを作成します。

go work initは、ワークスペースモジュールへのパスを引数としてオプションで受け入れます。 引数が省略された場合、モジュールがない空のワークスペースが作成されます。

各引数パスは、go.workファイルのuseディレクティブに追加されます。 現在のgoバージョンもgo.workファイルに記載されます。

詳細情報については、https://go.dev/ref/mod#workspaces のワークスペースリファレンスを参照してください。

ワークスペースのビルドリストをモジュールに同期

使用法：

go work sync

Syncは、ワークスペースのビルドリストをワークスペースのモジュールに同期します。

ワークスペースのビルドリストは、ワークスペース内でビルドを行うために使用されるすべての （トランジティブな）依存モジュールのバージョンのセットです。go work syncは、 最小バージョン選択アルゴリズムを使用してそのビルドリストを生成し、 そのバージョンをワークスペース内で指定された各モジュールに同期します（useディレクティブで）。

同期は、ワークスペースモジュールで指定された各依存モジュールを、 依存モジュールのバージョンがすでにビルドリストのバージョンと同じでない場合、 ビルドリストのバージョンに順次アップグレードすることによって行われます。 最小バージョン選択が、各モジュールのビルドリストのバージョンが常に各ワークスペースモジュールの バージョンと同じかそれ以上であることを保証することに注意してください。

詳細情報については、https://go.dev/ref/mod#workspaces のワークスペースリファレンスを参照してください。

ワークスペースファイルにモジュールを追加

使用法：

go work use [-r] [moddirs]

Useは、ディレクトリをオプションで再帰的にgo.workファイルに追加するための コマンドラインインターフェースを提供します。

コマンドライン上の各引数ディレクトリに対してuseディレクティブがgo.workファイルに追加されます。 それが存在する場合はgo.workファイルに、存在しない場合はgo.workファイルから削除されます。 残りのuseディレクティブが存在しないモジュールを参照している場合、Useは失敗します。

Useは、go.workのgo行を更新して、使用されるモジュールのすべてのgo行と同じか それ以上のバージョンを指定します。これは、既存のものと新しく追加されたものの両方です。 引数がない場合、この更新はgo work useが行う唯一のことです。

-rフラグは、引数ディレクトリでモジュールを再帰的に検索し、 useコマンドは、それぞれのディレクトリが引数として指定されたかのように動作します： つまり、存在するディレクトリにはuseディレクティブが追加され、存在しないディレクトリには削除されます。

詳細情報については、https://go.dev/ref/mod#workspaces のワークスペースリファレンスを参照してください。

Goプログラムのコンパイルと実行

使用法：

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

Runは、指定されたmain Goパッケージをコンパイルして実行します。 通常、パッケージは単一のディレクトリからの.goソースファイルのリストとして指定されますが、 インポートパス、ファイルシステムパス、または 'go run .' や 'go run my/cmd' のように 単一の既知のパッケージに一致するパターンでもかまいません。

パッケージ引数にバージョン接尾辞（@latestや@v1.0.0のような）がある場合、 "go run"はモジュール対応モードでプログラムをビルドし、現在のディレクトリや ある場合は親ディレクトリのgo.modファイルを無視します。これは、メインモジュールの 依存関係に影響を与えずにプログラムを実行するのに便利です。

パッケージ引数にバージョン接尾辞がない場合、"go run"はGO111MODULE環境変数と go.modファイルの存在に応じて、モジュール対応モードまたはGOPATHモードで実行されるかもしれません。 詳細は 'go help modules' を参照してください。モジュール対応モードが有効になっている場合、 "go run"はメインモジュールのコンテキストで実行されます。

デフォルトでは、'go run'はコンパイルされたバイナリを直接実行します：'a.out arguments...'. -execフラグが指定されている場合、'go run'はxprogを使用してバイナリを起動します：

'xprog a.out arguments...'.

-execフラグが指定されていない場合、GOOSまたはGOARCHがシステムのデフォルトと異なり、 そしてプログラム名がgo_$GOOS_$GOARCH_execで見つかる場合、 'go run'はそのプログラムを使用してバイナリを起動します。 例えば 'go_js_wasm_exec a.out arguments...'. これにより、シミュレーターや他の実行方法が 利用可能な場合にクロスコンパイルされたプログラムを実行できます。

デフォルトでは、'go run'はビルド時間を短縮するためにデバッガーが使用する情報を生成せずに バイナリをコンパイルします。バイナリにデバッガー情報を含めるには、'go build'を使用します。

Runの終了ステータスは、コンパイルされたバイナリの終了ステータスではありません。

ビルドフラグについての詳細は、'go help build'を参照してください。 パッケージの指定についての詳細は、'go help packages'を参照してください。

参照：go build.

パッケージのテスト

使用法：

go test [ビルド/テストフラグ] [パッケージ] [ビルド/テストフラグ & テストバイナリフラグ]

'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 testはgo vetをパッケージと そのテストソースファイルに対して実行し、重大な問題を特定します。もしgo vetが 何か問題を見つけた場合、go testはそれらを報告し、テストバイナリを実行しません。 使われるのは、デフォルトのgo vetチェックの高信頼度のサブセットだけです。 そのサブセットは次の通りです：atomic, bool, buildtags, directive, errorsas, ifaceassert, nilfunc, printf, そして stringintconv。これらと他のvetテストの ドキュメンテーションは "go doc cmd/vet"を通じて見ることができます。 go vetの実行を無効にするには、-vet=offフラグを使用します。すべての チェックを実行するには、-vet=allフラグを使用します。

すべてのテスト出力とサマリーラインは、テストが自身の標準エラーにそれらを出力したとしても、 goコマンドの標準出力に印刷されます。（goコマンドの標準エラーは、テストのビルドエラーを印刷するために予約されています。）

goコマンドは、テストの環境で$PATHの先頭に$GOROOT/binを配置します。 これにより、'go'コマンドを実行するテストは、親の'go test'コマンドと同じ'go'を使用します。

Goテストは2つの異なるモードで実行されます：

最初のモードは、ローカルディレクトリモードと呼ばれ、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はパッケージテストがいずれかで失敗した場合に最終的な 'FAIL' ステータスを印刷します。

パッケージリストモードのみで、go testは成功したパッケージテストの結果をキャッシュして、 テストの不必要な繰り返し実行を避けます。テストの結果がキャッシュから回復できるとき、 go testはテストバイナリを再度実行する代わりに前回の出力を再表示します。これが発生すると、 go testはサマリーラインの経過時間の代わりに '(cached)' を印刷します。

キャッシュに一致するルールは、実行が同じテストバイナリを含み、コマンドライン上のフラグが全て 'キャッシュ可能'なテストフラグの制限されたセットから来るというものです。これらのフラグには -benchtime, -cpu, -list, -parallel, -run, -short, -timeout, -failfast, そして -vが含まれます。 go testの実行がこのセット外の任意のテストフラグまたは非テストフラグを持つ場合、結果はキャッシュされません。 テストキャッシュを無効にするには、キャッシュ可能なフラグ以外の任意のテストフラグまたは引数を使用します。 テストキャッシュを明示的に無効にする慣用的な方法は、-count=1を使用することです。パッケージのソースルート内 （通常は$GOPATH）でファイルを開くテストや、環境変数を参照するテストは、ファイルと環境変数が変更されない 未来の実行とのみ一致します。キャッシュされたテスト結果は全く時間がかからないとして扱われるため、 成功したパッケージテスト結果は-timeout設定に関係なくキャッシュされ、再利用されます。

ビルドフラグに加えて、'go test'自体が処理するフラグは以下の通りです：

-args
    コマンドラインの残りの部分（-argsの後のすべて）を、解釈せずに変更せずにテストバイナリに渡します。
    このフラグはコマンドラインの残りの部分を消費するため、パッケージリスト（存在する場合）はこのフラグの前に表示される必要があります。

-c
    テストバイナリを現在のディレクトリのpkg.testにコンパイルしますが、実行はしません
    （ここで、pkgはパッケージのインポートパスの最後の要素です）。
    ファイル名またはターゲットディレクトリは-oフラグで変更できます。

-exec xprog
    xprogを使用してテストバイナリを実行します。振る舞いは
    'go run'と同じです。詳細は'go help run'を参照してください。

-json
    テスト出力を自動処理に適したJSONに変換します。
    エンコーディングの詳細については'go doc test2json'を参照してください。

-o file
    テストバイナリを指定したファイルにコンパイルします。
    テストはまだ実行されます（-cまたは-iが指定されていない限り）。
    もしファイルがスラッシュで終わっているか、既存のディレクトリを指定している場合、
    テストはそのディレクトリのpkg.testに書き込まれます。

テストバイナリは、テストの実行を制御するフラグも受け入れます。これらの フラグは'go test'でもアクセス可能です。詳細は'go help testflag'を参照してください。

ビルドフラグについての詳細は、'go help build'を参照してください。 パッケージの指定についての詳細は、'go help packages'を参照してください。

参照：go build, go vet.

指定されたgoツールを実行

使用法：

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

Toolは、引数で識別されるgoツールコマンドを実行します。 引数がない場合、既知のツールのリストを表示します。

-nフラグは、toolに実行されるコマンドを表示させるが実行はさせないようにします。

各ツールコマンドの詳細については、'go doc cmd/<command>'を参照してください。

Goバージョンを表示

使用法：

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

Versionは、Goバイナリファイルのビルド情報を表示します。

Go versionは、指定された各ファイルをビルドするために使用されたGoのバージョンを報告します。

コマンドライン上でファイルが指定されていない場合、go versionは自身の バージョン情報を表示します。

ディレクトリが指定されている場合、go versionはそのディレクトリを再帰的に走査し、 認識されたGoのバイナリを探し、そのバージョンを報告します。 デフォルトでは、go versionはディレクトリスキャン中に見つかった認識されないファイルを報告しません。 -vフラグを使用すると、認識されないファイルを報告します。

-mフラグを使用すると、go versionは各ファイルの埋め込まれた モジュールバージョン情報を表示します（利用可能な場合）。出力では、モジュール 情報はバージョンラインに続く複数の行で構成され、各行は先頭のタブ文字でインデントされます。

参照：go doc runtime/debug.BuildInfo.

パッケージのおそらく間違いを報告

使用法：

go vet [ビルドフラグ] [-vettool prog] [vetフラグ] [パッケージ]

Vetは、インポートパスで指定されたパッケージに対してGo vetコマンドを実行します。

vetとそのフラグについての詳細は、'go doc cmd/vet'を参照してください。 パッケージの指定についての詳細は、'go help packages'を参照してください。 チェッカーとそのフラグのリストについては、'go tool vet help'を参照してください。 'printf'のような特定のチェッカーの詳細については、'go tool vet help printf'を参照してください。

-vettool=progフラグは、代替または追加のチェックを持つ別の分析ツールを選択します。 例えば、'shadow'アナライザは、これらのコマンドを使用してビルドおよび実行できます：

go install golang.org/x/tools/go/analysis/passes/shadow/cmd/shadow@latest
go vet -vettool=$(which shadow)

go vetがサポートするビルドフラグは、パッケージの解決と実行を制御するものです。 例えば、-C, -n, -x, -v, -tags, そして -toolexecです。 これらのフラグについての詳細は、'go help build'を参照してください。

参照：go fmt, go fix.

ビルド制約

ビルド制約、またはビルドタグとは、ファイルがパッケージに含まれるべき条件です。 ビルド制約は次のように始まる行コメントで与えられます：

//go:build

制約は任意の種類のソースファイル（Goだけでなく）に現れることができますが、 ファイルの上部近く、空行や他の行コメントのみに先行して現れる必要があります。 これらのルールは、Goファイルではビルド制約がパッケージ節の前に現れなければならないことを意味します。

ビルド制約とパッケージのドキュメンテーションを区別するために、 ビルド制約の後には空行を入れるべきです。

ビルド制約コメントは、||、&&、および！演算子および括弧によって組み合わされた ビルドタグを含む式として評価されます。演算子はGoと同じ意味を持ちます。

例えば、次のビルド制約は、"linux"と"386"の制約が満たされているとき、または "darwin"が満たされていて"cgo"が満たされていないときに、ファイルをビルドするように制約します：

//go:build (linux && 386) || (darwin && !cgo)

ファイルに複数の//go:build行がある場合はエラーです。

特定のビルド中に、以下のビルドタグが満たされます：

• ターゲットとなるオペレーティングシステム、runtime.GOOSによって表現され、 GOOS環境変数で設定されます。
• ターゲットとなるアーキテクチャ、runtime.GOARCHによって表現され、 GOARCH環境変数で設定されます。
• 任意のアーキテクチャ機能、GOARCH.featureの形式で （例えば、"amd64.v2"）、詳細は以下を参照してください。
• "unix"、もしGOOSがUnixまたはUnix風のシステムである場合。
• 使用されているコンパイラ、"gc"または"gccgo"
• "cgo"、もしcgoコマンドがサポートされている場合（'go help environment'のCGO_ENABLEDを参照）。
• 各Goメジャーリリースに対する用語、現在のバージョンまで： Goバージョン1.1以降は"go1.1"、Go 1.12からは"go1.12"、など。
• -tagsフラグによって与えられた任意の追加タグ（'go help build'を参照）。

ベータ版やマイナーリリースに対する別のビルドタグはありません。

ファイル名が、拡張子と可能な_test接尾辞を削除した後、以下のパターンのいずれかと一致する場合：

*_GOOS
*_GOARCH
*_GOOS_GOARCH

(例：source_windows_amd64.go) ここで、GOOSとGOARCHはそれぞれ任意の既知のオペレーティングシステムと アーキテクチャの値を表します。その場合、ファイルはそれらの項目を必要とする暗黙のビルド制約を持つと 考えられます（ファイル内の明示的な制約に加えて）。

GOOS=androidを使用すると、androidのタグとファイルに加えて、GOOS=linuxのビルドタグとファイルに一致します。

GOOS=illumosを使用すると、illumosのタグとファイルに加えて、GOOS=solarisのビルドタグとファイルに一致します。

GOOS=iosを使用すると、iosのタグとファイルに加えて、GOOS=darwinのビルドタグとファイルに一致します。

定義されたアーキテクチャ機能のビルドタグは以下の通りです：

• GOARCH=386の場合、GO386=387とGO386=sse2は それぞれ386.387と386.sse2のビルドタグを設定します。
• GOARCH=amd64の場合、GOAMD64=v1、v2、およびv3は amd64.v1、amd64.v2、およびamd64.v3の機能ビルドタグに対応します。
• GOARCH=armの場合、GOARM=5、6、および7は arm.5、arm.6、およびarm.7の機能ビルドタグに対応します。
• GOARCH=mipsまたはmipsleの場合、 GOMIPS=hardfloatとsoftfloatは mips.hardfloatとmips.softfloat （またはmipsle.hardfloatとmipsle.softfloat）の機能ビルドタグに対応します。
• GOARCH=mips64またはmips64leの場合、 GOMIPS64=hardfloatとsoftfloatは mips64.hardfloatとmips64.softfloat （またはmips64le.hardfloatとmips64le.softfloat）の機能ビルドタグに対応します。
• GOARCH=ppc64またはppc64leの場合、 GOPPC64=power8、power9、およびpower10は ppc64.power8、ppc64.power9、およびppc64.power10 （またはppc64le.power8、ppc64le.power9、およびppc64le.power10） の機能ビルドタグに対応します。
• GOARCH=wasmの場合、GOWASM=satconvとsignextは wasm.satconvとwasm.signextの機能ビルドタグに対応します。

GOARCH=amd64、arm、ppc64、およびppc64leの場合、特定の機能レベルは すべての前のレベルの機能ビルドタグも設定します。 例えば、GOAMD64=v2はamd64.v1とamd64.v2の機能フラグを設定します。 これにより、たとえば、GOAMD64=v4が導入されたときでも、 v2の機能を使用するコードがコンパイルを続けることが保証されます。 特定の機能レベルの欠如を処理するコードは、否定を使用する必要があります：

//go:build !amd64.v2

ファイルがどのビルドでも考慮されないようにするには：

//go:build ignore

(他の満たされない単語でも機能しますが、"ignore"が慣習的です。)

ファイルをcgoを使用してのみビルドし、LinuxとOS Xでのみビルドするには：

//go:build cgo && (linux || darwin)

そのようなファイルは通常、他のシステムのデフォルトの機能を実装する 別のファイルとペアになり、この場合、制約を持つことになります：

//go:build !(cgo && (linux || darwin))

ファイル名をdns_windows.goとすると、Windows用のパッケージをビルドするときにのみ 含まれます。同様に、math_386.sは32ビットx86のパッケージをビルドするときにのみ含まれます。

Goのバージョン1.16以前では、ビルド制約には異なる構文が使用されていました。 それは"// +build"プレフィックスでした。gofmtコマンドは、古い構文に遭遇すると、 同等の//go:build制約を追加します。

ビルドモード

'go build'と'go install'コマンドは-buildmode引数を取り、 どの種類のオブジェクトファイルをビルドするかを示します。現在サポートされている値は以下の通りです：

-buildmode=archive
	リストされた非メインパッケージを.aファイルにビルドします。mainと名付けられたパッケージは無視されます。

-buildmode=c-archive
	リストされたメインパッケージとそれがインポートするすべてのパッケージを
	Cアーカイブファイルにビルドします。呼び出し可能なシンボルは、cgo //exportコメントを使用して
	エクスポートされた関数だけになります。リストされるメインパッケージは1つだけでなければなりません。

-buildmode=c-shared
	リストされたメインパッケージとそれがインポートするすべてのパッケージを
	C共有ライブラリにビルドします。呼び出し可能なシンボルは、cgo //exportコメントを使用して
	エクスポートされた関数だけになります。リストされるメインパッケージは1つだけでなければなりません。

-buildmode=default
	リストされたメインパッケージは実行可能ファイルに、リストされた非メインパッケージは.aファイルに
	ビルドされます（デフォルトの挙動）。

-buildmode=shared
	リストされたすべての非メインパッケージを単一の共有ライブラリに結合し、
	-linksharedオプションでビルドする際に使用します。mainと名付けられたパッケージは無視されます。

-buildmode=exe
	リストされたメインパッケージとそれらがインポートするすべてを実行可能ファイルにビルドします。
	mainと名付けられていないパッケージは無視されます。

-buildmode=pie
	リストされたメインパッケージとそれらがインポートするすべてを
	位置独立実行可能ファイル（PIE）にビルドします。mainと名付けられていないパッケージは無視されます。

-buildmode=plugin
	リストされたメインパッケージとそれらがインポートするすべてをGoプラグインにビルドします。
	mainと名付けられていないパッケージは無視されます。

AIXでは、-buildmode=c-archiveでビルドされたGoアーカイブを使用するCプログラムをリンクするときは、 Cコンパイラに-Wl,-bnoobjreorderを渡す必要があります。

GoとC間の呼び出し

GoとC/C++コード間で呼び出しを行う方法は2つあります。

最初の方法は、Goディストリビューションの一部であるcgoツールです。 その使用方法については、cgoのドキュメンテーション（go doc cmd/cgo）を参照してください。

2つ目の方法は、SWIGプログラムで、これは言語間のインターフェースを作成する一般的なツールです。 SWIGについての情報は、http://swig.org/ を参照してください。 go buildを実行するとき、.swig拡張子を持つ任意のファイルはSWIGに渡されます。 .swigcxx拡張子を持つ任意のファイルは、-c++オプション付きでSWIGに渡されます。

cgoまたはSWIGを使用するとき、go buildは任意の.c、.m、.s、.S または.sxファイルをCコンパイラに、任意の.cc、.cpp、.cxxファイルをC++ コンパイラに渡します。CCまたはCXX環境変数を設定すると、それぞれ使用するCまたはC++ コンパイラを決定できます。

ビルドとテストのキャッシング

goコマンドはビルドの出力をキャッシュして、将来のビルドで再利用します。 キャッシュデータのデフォルトの場所は、現在のオペレーティングシステムの標準ユーザーキャッシュディレクトリ内の go-buildという名前のサブディレクトリです。GOCACHE環境変数を設定すると、このデフォルトが上書きされます。 'go env GOCACHE'を実行すると、現在のキャッシュディレクトリが表示されます。

goコマンドは定期的に最近使用されていないキャッシュデータを削除します。 'go clean -cache'を実行すると、すべてのキャッシュデータが削除されます。

ビルドキャッシュはGoのソースファイル、コンパイラ、コンパイラオプションなどの変更を正しく反映します。 そのため、通常の使用ではキャッシュを明示的にクリーンアップする必要はありません。ただし、ビルドキャッシュは cgoでインポートされたCライブラリの変更を検出しません。システムのCライブラリに変更を加えた場合、 キャッシュを明示的にクリーンアップするか、更新されたCライブラリに依存するパッケージの再ビルドを強制するために -aビルドフラグを使用する必要があります（'go help build'を参照してください）。

goコマンドは、成功したパッケージテストの結果もキャッシュします。 詳細は 'go help test' を参照してください。'go clean -testcache' を実行すると、 すべてのキャッシュされたテスト結果が削除されます（ただし、キャッシュされたビルド結果は削除されません）。

goコマンドはまた、'go test -fuzz' で使用されるファジングの値もキャッシュします。 具体的には、ファズ関数に渡されたときにコードカバレッジを拡大した値です。これらの値は通常のビルドや テストには使用されませんが、ビルドキャッシュのサブディレクトリに保存されます。 'go clean -fuzzcache' を実行すると、すべてのキャッシュされたファジング値が削除されます。 これにより、一時的にファジングが効果的でなくなる可能性があります。

GODEBUG環境変数を設定すると、キャッシュの状態に関するデバッグ情報の出力を有効にできます：

GODEBUG=gocacheverify=1 を設定すると、goコマンドはキャッシュのエントリの使用をバイパスし、 代わりにすべてを再ビルドし、結果が既存のキャッシュエントリと一致するかどうかを確認します。

GODEBUG=gocachehash=1 を設定すると、goコマンドはキャッシュのルックアップキーを構築するために使用する すべてのコンテンツハッシュの入力を出力します。出力は大量ですが、キャッシュのデバッグに役立ちます。

GODEBUG=gocachetest=1 を設定すると、goコマンドはキャッシュされたテスト結果を再利用するかどうかの 決定についての詳細を出力します。

環境変数

goコマンドとそれが呼び出すツールは、設定のために環境変数を参照します。 環境変数が設定されていないか空の場合、goコマンドは適切なデフォルト設定を使用します。 変数<NAME>の有効な設定を見るには、'go env <NAME>'を実行します。 デフォルト設定を変更するには、'go env -w <NAME>=<VALUE>'を実行します。 'go env -w'を使用して変更されたデフォルトは、os.UserConfigDirによって報告される ユーザーごとの設定ディレクトリに保存されるGo環境設定ファイルに記録されます。 設定ファイルの場所は、環境変数GOENVを設定することで変更できます。 'go env GOENV'は有効な場所を出力しますが、'go env -w'はデフォルトの場所を変更できません。 詳細は 'go help env' を参照してください。

汎用的な環境変数:

GO111MODULE
	goコマンドがモジュール対応モードで実行するか、GOPATHモードで実行するかを制御します。
	"off"、"on"、"auto"のいずれかになります。
	詳細は https://golang.org/ref/mod#mod-commands を参照してください。
GCCGO
	'go build -compiler=gccgo'で実行するgccgoコマンド。
GOARCH
	コードをコンパイルするアーキテクチャ、またはプロセッサ。
	例えばamd64、386、arm、ppc64など。
GOBIN
	'go install'がコマンドをインストールするディレクトリ。
GOCACHE
	goコマンドが将来のビルドで再利用するためのキャッシュ情報を保存するディレクトリ。
GOMODCACHE
	goコマンドがダウンロードしたモジュールを保存するディレクトリ。
GODEBUG
	各種デバッグ機能を有効にします。詳細は https://go.dev/doc/godebug を参照してください。
GOENV
	Go環境設定ファイルの場所。
	'go env -w'を使用して設定することはできません。
	環境でGOENV=offを設定すると、デフォルトの設定ファイルの使用が無効になります。
GOFLAGS
	デフォルトでgoコマンドに適用する-flag=value設定のスペース区切りのリスト。
	各エントリはスタンドアロンのフラグでなければなりません。
	エントリはスペースで区切られているため、フラグの値にはスペースを含めることはできません。
	コマンドラインにリストされたフラグは、このリストの後に適用されるため、それを上書きします。
GOINSECURE
	常に安全でない方法で取得するべきモジュールパスのプレフィックスのグロブパターンのカンマ区切りのリスト
	（Goのpath.Matchの構文）。
	直接取得される依存関係にのみ適用されます。
	GOINSECUREはチェックサムデータベースの検証を無効にしません。それを達成するためにはGOPRIVATEまたは
	GONOSUMDBを使用します。
GOOS
	コードをコンパイルするオペレーティングシステム。
	例えばlinux、darwin、windows、netbsdなど。
GOPATH
	さまざまなファイルが保存される場所を制御します。詳細は 'go help gopath' を参照してください。
GOPROXY
	GoモジュールプロキシのURL。詳細は https://golang.org/ref/mod#environment-variables
	および https://golang.org/ref/mod#module-proxy を参照してください。
GOPRIVATE, GONOPROXY, GONOSUMDB
	常に直接取得するべきモジュールパスのプレフィックスのグロブパターンのカンマ区切りのリスト
	（Goのpath.Matchの構文）。
	または、チェックサムデータベースと比較すべきでないもの。
	詳細は https://golang.org/ref/mod#private-modules を参照してください。
GOROOT
	goツリーのルート。
GOSUMDB
	使用するチェックサムデータベースの名前と、オプションでその公開鍵と
	URL。詳細は https://golang.org/ref/mod#authenticating を参照してください。
GOTOOLCHAIN
	使用するGoツールチェーンを制御します。詳細は https://go.dev/doc/toolchain を参照してください。
GOTMPDIR
	goコマンドが一時的なソースファイル、パッケージ、バイナリを書き込むディレクトリ。
GOVCS
	一致するサーバーで使用できるバージョン管理コマンドのリスト。
	詳細は 'go help vcs' を参照してください。
GOWORK
	モジュール対応モードでは、指定されたgo.workファイルをワークスペースファイルとして使用します。
	デフォルトまたはGOWORKが"auto"の場合、goコマンドは現在のディレクトリとその含まれるディレクトリで
	go.workという名前のファイルを探します。有効なgo.workファイルが見つかった場合、指定されたモジュールは
	まとめてメインモジュールとして使用されます。GOWORKが"off"、または"auto"モードでgo.workファイルが見つからない場合、
	ワークスペースモードは無効になります。

cgoを使用するための環境変数:

AR
	gccgoコンパイラでビルドする際にライブラリアーカイブを操作するために使用するコマンド。
	デフォルトは 'ar' です。
CC
	Cコードをコンパイルするために使用するコマンド。
CGO_ENABLED
	cgoコマンドがサポートされているかどうか。0または1。
CGO_CFLAGS
	cgoがCコードをコンパイルする際にコンパイラに渡すフラグ。
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++コードをコンパイルするために使用するコマンド。
FC
	Fortranコードをコンパイルするために使用するコマンド。
PKG_CONFIG
	pkg-configツールへのパス。

アーキテクチャ固有の環境変数:

GOARM
	GOARCH=armの場合、コンパイルするARMアーキテクチャ。
	有効な値は5、6、7です。
GO386
	GOARCH=386の場合、浮動小数点命令の実装方法。
	有効な値はsse2（デフォルト）、softfloatです。
GOAMD64
	GOARCH=amd64の場合、コンパイルするマイクロアーキテクチャレベル。
	有効な値はv1（デフォルト）、v2、v3、v4です。
	詳細は https://golang.org/wiki/MinimumRequirements#amd64 を参照してください。
GOMIPS
	GOARCH=mips{,le}の場合、浮動小数点命令を使用するかどうか。
	有効な値はhardfloat（デフォルト）、softfloatです。
GOMIPS64
	GOARCH=mips64{,le}の場合、浮動小数点命令を使用するかどうか。
	有効な値はhardfloat（デフォルト）、softfloatです。
GOPPC64
	GOARCH=ppc64{,le}の場合、ターゲットISA（Instruction Set Architecture）。
	有効な値はpower8（デフォルト）、power9、power10です。
GOWASM
	GOARCH=wasmの場合、使用する実験的なWebAssembly機能のカンマ区切りのリスト。
	有効な値はsatconv、signextです。

コードカバレッジに使用する環境変数:

GOCOVERDIR
	"go build -cover"バイナリを実行して生成されたコードカバレッジデータファイルを書き込むディレクトリ。
	GOEXPERIMENT=coverageredesignが有効になっている必要があります。

特別な目的の環境変数:

GCCGOTOOLDIR
	設定されている場合、cgoなどのgccgoツールを見つける場所。
	デフォルトはgccgoの設定方法に基づいています。
GOEXPERIMENT
	有効化または無効化するツールチェーンの実験のカンマ区切りのリスト。
	利用可能な実験のリストは時間とともに任意に変更される可能性があります。
	現在有効な値については、src/internal/goexperiment/flags.goを参照してください。
	警告: この変数はGoツールチェーン自体の開発とテストのために提供されています。
	それ以外の目的での使用はサポートされていません。
GOROOT_FINAL
	Goツリーがインストールされているルート、つまり、
	ビルドされた場所以外の場所にインストールされている場合。
	スタックトレースのファイル名はGOROOTからGOROOT_FINALに書き換えられます。
GO_EXTLINK_ENABLED
	cgoを使用するコードと-linkmode=autoを使用するときに、
	リンカーが外部リンクモードを使用するかどうか。
	外部リンクモードを無効にするには0、有効にするには1を設定します。
GIT_ALLOW_PROTOCOL
	Gitによって定義されます。git fetch/cloneで使用できるスキームのコロン区切りのリスト。
	設定されている場合、明示的に言及されていない任意のスキームは、'go get'によって安全でないと見なされます。
	変数はGitによって定義されているため、デフォルト値は'go env -w'を使用して設定できません。

'go env'から利用可能な追加情報（環境からは読み取られません）:

GOEXE
	実行可能ファイルの名前のサフィックス（Windowsでは".exe"、他のシステムでは""）。
GOGCCFLAGS
	CCコマンドに渡される引数のスペース区切りのリスト。
GOHOSTARCH
	Goツールチェーンバイナリのアーキテクチャ（GOARCH）。
GOHOSTOS
	Goツールチェーンバイナリのオペレーティングシステム（GOOS）。
GOMOD
	メインモジュールのgo.modへの絶対パス。
	モジュール対応モードが有効で、go.modがない場合、GOMODはos.DevNullになります
	（Unix系システムでは"/dev/null"、Windowsでは"NUL"）。
	モジュール対応モードが無効の場合、GOMODは空文字列になります。
GOTOOLDIR
	goツール（compile、cover、docなど）がインストールされているディレクトリ。
GOVERSION
	インストールされているGoツリーのバージョン。runtime.Versionによって報告されます。

ファイルタイプ

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, .sx
	アセンブラソースファイル。
	パッケージがcgoまたはSWIGを使用している場合、これらは
	OSネイティブのアセンブラ（通常はgcc（sic））でアセンブルされます。それ以外の場合は
	Goアセンブラでアセンブルされます。
.swig, .swigcxx
	SWIG定義ファイル。
.syso
	システムオブジェクトファイル。

.sysoを除くこれらのタイプの各ファイルにはビルド制約が含まれている場合がありますが、 goコマンドは、空行または//-スタイルの行コメントでないファイルの最初の項目で ビルド制約のスキャンを停止します。詳細はgo/buildパッケージのドキュメンテーションを参照してください。

go.modファイル

モジュールのバージョンは、そのルートにgo.modファイルを持つソースファイルのツリーによって定義されます。 goコマンドが実行されると、現在のディレクトリとその親ディレクトリを順に探し、 メイン（現在の）モジュールのルートをマークするgo.modを見つけます。

go.modファイルの形式は、https://golang.org/ref/mod#go-mod-file で詳しく説明されています。

新しいgo.modファイルを作成するには、'go mod init'を使用します。詳細は 'go help mod init'またはhttps://golang.org/ref/mod#go-mod-initを参照してください。

不足しているモジュール要件を追加したり、不要な要件を削除したりするには、 'go mod tidy'を使用します。詳細は、'go help mod tidy'または https://golang.org/ref/mod#go-mod-tidyを参照してください。

特定のモジュール要件を追加、アップグレード、ダウングレード、または削除するには、 'go get'を使用します。詳細は、'go help module-get'または https://golang.org/ref/mod#go-getを参照してください。

他の変更を加えたり、go.modをJSONとして解析して他のツールで使用したりするには、 'go mod edit'を使用します。'go help mod edit'または https://golang.org/ref/mod#go-mod-editを参照してください。

GOPATH環境変数

Goパスはインポート文を解決するために使用されます。 これはgo/buildパッケージによって実装され、そのパッケージで文書化されています。

GOPATH環境変数は、Goのコードを探す場所をリストします。 Unixでは、値はコロンで区切られた文字列です。 Windowsでは、値はセミコロンで区切られた文字列です。 Plan 9では、値はリストです。

環境変数が設定されていない場合、GOPATHはデフォルトで ユーザーのホームディレクトリ内の"go"という名前のサブディレクトリになります （Unixでは$HOME/go、Windowsでは%USERPROFILE%\go）。 ただし、そのディレクトリがGoのディストリビューションを保持している場合は除きます。 現在のGOPATHを見るには、"go env GOPATH"を実行します。

カスタムGOPATHを設定するには、https://golang.org/wiki/SettingGOPATH を参照してください。

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/               (パッケージbarのgoコード)
                x.go
            quux/              (パッケージmainのgoコード)
                y.go
    bin/
        quux                   (インストールされたコマンド)
    pkg/
        linux_amd64/
            foo/
                bar.a          (インストールされたパッケージオブジェクト)

Goはソースコードを見つけるために、GOPATHにリストされた各ディレクトリを検索しますが、 新しいパッケージは常にリストの最初のディレクトリにダウンロードされます。

例については、https://golang.org/doc/code.html を参照してください。

GOPATHとモジュール

モジュールを使用すると、GOPATHはインポートの解決にはもはや使用されません。 しかし、ダウンロードしたソースコード（GOPATH/pkg/mod内）と コンパイルされたコマンド（GOPATH/bin内）を保存するためにまだ使用されます。

内部ディレクトリ

"internal"という名前のディレクトリ内またはその下のコードは、 "internal"の親でルート化されたディレクトリツリー内のコードのみがインポート可能です。 上記のディレクトリレイアウトの拡張版を以下に示します：

/home/user/go/
    src/
        crash/
            bang/              (パッケージbangのgoコード)
                b.go
        foo/                   (パッケージfooのgoコード)
            f.go
            bar/               (パッケージbarのgoコード)
                x.go
            internal/
                baz/           (パッケージbazのgoコード)
                    z.go
            quux/              (パッケージmainのgoコード)
                y.go

z.goのコードは"foo/internal/baz"としてインポートされますが、 そのインポート文は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には、外部依存関係のローカルコピーを使用して、 それらの依存関係のインポートを満たすためのサポートが含まれています。 これは一般的にベンダリングと呼ばれます。

"vendor"という名前のディレクトリ以下のコードは、 "vendor"の親でルート化されたディレクトリツリー内のコードのみがインポート可能であり、 ベンダー要素までのプレフィックスを省略したインポートパスのみを使用します。

以下に前のセクションの例を示しますが、 "internal"ディレクトリが"vendor"に名前変更され、 新たにfoo/vendor/crash/bangディレクトリが追加されています：

/home/user/go/
    src/
        crash/
            bang/              (パッケージbangのgoコード)
                b.go
        foo/                   (パッケージfooのgoコード)
            f.go
            bar/               (パッケージbarのgoコード)
                x.go
            vendor/
                crash/
                    bang/      (パッケージbangのgoコード)
                        b.go
                baz/           (パッケージbazのgoコード)
                    z.go
            quux/              (パッケージmainのgoコード)
                y.go

内部と同じ可視性ルールが適用されますが、z.goのコードは "foo/vendor/baz"ではなく"baz"としてインポートされます。

ソースツリー内でより深いベンダーディレクトリのコードは、 上位ディレクトリのコードをシャドウします。fooでルート化されたサブツリー内では、 "crash/bang"のインポートはトップレベルの"crash/bang"ではなく "foo/vendor/crash/bang"に解決されます。

ベンダーディレクトリ内のコードはインポートパスのチェックの対象ではありません ('go help importpath'を参照)。

'go get'がgitリポジトリをチェックアウトまたは更新するとき、 それは今やサブモジュールも更新します。

ベンダーディレクトリは、'go get'によって初めてチェックアウトされる 新しいリポジトリの配置に影響しません：それらは常にメインのGOPATHに配置され、 ベンダーサブツリーには配置されません。

詳細は https://golang.org/s/go15vendor を参照してください。

レガシーGOPATH go get

'go get'コマンドは、goコマンドがモジュール対応モードで動作しているか、 レガシーGOPATHモードで動作しているかによって、振る舞いが変わります。 このヘルプテキストは、モジュール対応モードでも'go help gopath-get'としてアクセス可能で、 レガシーGOPATHモードでの'go get'の動作を説明しています。

使用法: go get [-d] [-f] [-t] [-u] [-v] [-fix] [build flags] [packages]

Getは、インポートパスによって指定されたパッケージとその依存関係をダウンロードします。 その後、指定されたパッケージをインストールします。これは'go install'と同様です。

-dフラグは、getにパッケージのダウンロード後に停止するよう指示します。 つまり、getにパッケージをインストールしないよう指示します。

-fフラグは、-uが設定されている場合のみ有効で、get -uに対して、 各パッケージがそのインポートパスから暗示されるソースコントロールリポジトリから チェックアウトされたことを確認しないよう強制します。これは、ソースがオリジナルのローカルフォークである場合に便利です。

-fixフラグは、getに依存関係を解決したりコードをビルドしたりする前に、 ダウンロードしたパッケージでfixツールを実行するよう指示します。

-tフラグは、getに指定されたパッケージのテストをビルドするために必要なパッケージもダウンロードするよう指示します。

-uフラグは、getにネットワークを使用して指定されたパッケージとその依存関係を更新するよう指示します。 デフォルトでは、getは欠落しているパッケージをチェックアウトするためにネットワークを使用しますが、 既存のパッケージの更新を探すためには使用しません。

-vフラグは、詳細な進行状況とデバッグ出力を有効にします。

Getはまた、インストールを制御するためのビルドフラグも受け入れます。詳細は'go help build'を参照してください。

新しいパッケージをチェックアウトするとき、getはターゲットディレクトリ GOPATH/src/<import-path>を作成します。もしGOPATHが複数のエントリを含んでいる場合、 getは最初のものを使用します。詳細は 'go help gopath' を参照してください。

パッケージをチェックアウトまたは更新するとき、getはローカルにインストールされたGoのバージョンと 一致するブランチまたはタグを探します。最も重要なルールは、ローカルのインストールがバージョン "go1" を 実行している場合、getは "go1" という名前のブランチまたはタグを探します。そのようなバージョンが存在しない場合、 パッケージのデフォルトブランチを取得します。

go getがGitリポジトリをチェックアウトまたは更新するとき、 それはまた、リポジトリによって参照される任意のgitサブモジュールも更新します。

Getは、ベンダーディレクトリに格納されたコードをチェックアウトまたは更新しません。

ビルドフラグについての詳細は、'go help build'を参照してください。

パッケージの指定についての詳細は、'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モジュールプロキシは、指定された形式のURLに対するGETリクエストに応答できる任意のWebサーバーです。 リクエストにはクエリパラメータがないため、固定のファイルシステムから提供されるサイト（file:/// URLを含む）でも モジュールプロキシになることができます。

GOPROXYプロトコルの詳細については、 https://golang.org/ref/mod#goproxy-protocol を参照してください。

インポートパスの構文

インポートパス（'go help packages'を参照）は、ローカルファイルシステムに保存されているパッケージを示します。 一般的に、インポートパスは標準パッケージ（例："unicode/utf8"）またはワークスペースの一つに見つかるパッケージを示します （詳細は 'go help gopath'を参照）。

相対インポートパス

./または../で始まるインポートパスを相対パスと呼びます。 ツールチェーンは、2つの方法で相対パスをショートカットとしてサポートしています。

まず、相対パスはコマンドライン上での省略形として使用できます。 "unicode"としてインポートされるコードを含むディレクトリで作業していて、 "unicode/utf8"のテストを実行したい場合、完全なパスを指定する代わりに "go test ./utf8"と入力できます。 同様に、逆の状況では、"unicode/utf8"ディレクトリから"unicode"をテストするには "go test .."と入力します。すべてのサブディレクトリをテストするための "go test ./..."のような相対パターンも許可されています。 パターン構文の詳細については、'go help packages'を参照してください。

二つ目、ワークスペース内でないGoプログラムをコンパイルしている場合、 そのプログラムのインポート文中で相対パスを使用して、ワークスペース外の近くのコードを参照できます。 これにより、通常のワークスペース外で小さなマルチパッケージプログラムを簡単に試すことができますが、 そのようなプログラムは "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  (フォールバック、正しく設定されたGOINSECUREの使用時のみ)

そのページがメタタグ

<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'を参照してください。)

モジュールを使用している場合、ダウンロードしたパッケージはモジュールキャッシュに保存されます。 https://golang.org/ref/mod#module-cache を参照してください。

モジュールを使用している場合、go-importメタタグの追加のバリアントが認識され、 バージョン管理システムをリストしているものよりも優先されます。 そのバリアントは、コンテンツ値のvcsとして"mod"を使用します。例えば：

<meta name="go-import" content="example.org mod https://code.org/moduleproxy">

このタグは、パスがexample.orgで始まるモジュールを、URL https://code.org/moduleproxyで利用可能なモジュールプロキシからフェッチすることを意味します。 プロキシプロトコルの詳細については、https://golang.org/ref/mod#goproxy-protocol を参照してください。

インポートパスのチェック

上記で説明したカスタムインポートパス機能が 既知のコードホスティングサイトにリダイレクトすると、 結果として得られる各パッケージには、カスタムドメインまたは既知のホスティングサイトを使用した 2つの可能なインポートパスがあります。

パッケージステートメントは、次の2つの形式のいずれかのコメントによって 直後（次の改行前）に続く場合、"インポートコメント"を持つと言われます：

package math // import "path"
package math /* import "path" */

goコマンドは、インポートコメントを持つパッケージをインストールを拒否します それがそのインポートパスによって参照されている場合を除きます。このように、インポートコメントを使用すると、 パッケージ作者はカスタムインポートパスが使用され、基礎となるコードホスティングサイトへの直接パスが使用されないことを確認できます。

ベンダーツリー内で見つかったコードに対してはインポートパスのチェックが無効化されます。 これにより、インポートコメントを更新することなく、コードをベンダーツリーの代替の場所にコピーすることが可能になります。

モジュールを使用している場合も、インポートパスのチェックは無効化されます。 インポートパスコメントは、go.modファイルのモジュールステートメントによって廃止されます。

詳細は https://golang.org/s/go14customimport を参照してください。

モジュール、モジュールのバージョン、その他

モジュールはGoが依存関係を管理する方法です。

モジュールは、パッケージの集合であり、一緒にリリース、バージョン管理、 配布されます。モジュールはバージョン管理リポジトリから直接ダウンロードすることも、 モジュールプロキシサーバーからダウンロードすることもできます。

モジュールに関する一連のチュートリアルについては、 https://golang.org/doc/tutorial/create-module を参照してください。

モジュールに関する詳細なリファレンスについては、https://golang.org/ref/mod を参照してください。

デフォルトでは、goコマンドはhttps://proxy.golang.orgからモジュールをダウンロードすることができます。 また、https://sum.golang.orgのチェックサムデータベースを使用してモジュールを認証することもできます。 これらのサービスは、GoogleのGoチームによって運営されています。 これらのサービスのプライバシーポリシーは、それぞれ https://proxy.golang.org/privacy と https://sum.golang.org/privacy で利用可能です。

goコマンドのダウンロード動作は、GOPROXY、GOSUMDB、GOPRIVATEなどの環境変数を使用して設定することができます。 詳細は 'go help environment' と https://golang.org/ref/mod#private-module-privacy を参照してください。

go.sumを使用したモジュール認証

goコマンドがモジュールのzipファイルやgo.modファイルをモジュールキャッシュにダウンロードするとき、 それは暗号学的ハッシュを計算し、それを既知の値と比較して、ファイルが初めてダウンロードされてから変更されていないことを確認します。 既知のハッシュは、モジュールのルートディレクトリにあるgo.sumという名前のファイルに保存されます。 ハッシュは、GOSUMDB、GOPRIVATE、およびGONOSUMDBの値に応じて、チェックサムデータベースからもダウンロードされることがあります。

詳細は、https://golang.org/ref/mod#authenticating を参照してください。

パッケージリストとパターン

多くのコマンドは一連のパッケージに適用されます：

go <action> [packages]

通常、[packages]はインポートパスのリストです。

ルートパスであるか、.または..要素で始まるインポートパスは、 ファイルシステムパスとして解釈され、そのディレクトリ内のパッケージを示します。

それ以外の場合、インポートパスPは、GOPATH環境変数にリストされている いくつかのDIRで、DIR/src/Pディレクトリに見つかるパッケージを示します （詳細は 'go help gopath' を参照してください）。

インポートパスが指定されていない場合、アクションは現在のディレクトリ内のパッケージに適用されます。

goツールでビルドするパッケージに対して使用すべきでない、4つの予約済みのパス名があります：

- "main"は、スタンドアロンの実行可能ファイルのトップレベルのパッケージを示します。

- "all"は、すべてのGOPATHツリーで見つかったすべてのパッケージに展開されます。 例えば、'go list all'はローカルシステム上のすべてのパッケージをリストします。 モジュールを使用している場合、"all"はメインモジュール内のすべてのパッケージと それらの依存関係に展開され、それらのいずれかのテストに必要な依存関係も含みます。

- "std"はallと似ていますが、標準のGoライブラリ内のパッケージだけに展開されます。

- "cmd"はGoリポジトリのコマンドとそれらの内部ライブラリに展開されます。

"cmd/"で始まるインポートパスは、Goリポジトリ内のソースコードのみに一致します。

インポートパスに1つ以上の"..."ワイルドカードが含まれている場合、それはパターンとなります。 これらのワイルドカードは、空文字列やスラッシュを含む文字列を含む任意の文字列に一致することができます。 このようなパターンは、GOPATHツリー内で見つかった名前がパターンに一致するすべてのパッケージディレクトリに展開されます。

よく使うパターンを便利にするために、2つの特別なケースがあります。 まず、パターンの最後の/...は空文字列に一致することができるため、 net/...はnetとそのサブディレクトリ内のパッケージ、例えばnet/httpの両方に一致します。 次に、ワイルドカードを含む任意のスラッシュで区切られたパターン要素は、 ベンダードパッケージのパスの"vendor"要素のマッチには参加しないため、 ./...は./vendorや./mycode/vendorのサブディレクトリ内のパッケージには一致しませんが、 ./vendor/...と./mycode/vendor/...は一致します。 ただし、コードを含むvendorという名前のディレクトリ自体はベンダードパッケージではないことに注意してください： cmd/vendorはvendorという名前のコマンドになり、パターンcmd/...はそれに一致します。 ベンダリングについての詳細は、golang.org/s/go15vendorを参照してください。

インポートパスは、リモートリポジトリからダウンロードされるパッケージを指定することもできます。 詳細は 'go help importpath' を実行してください。

プログラム内のすべてのパッケージは、一意のインポートパスを持つ必要があります。 慣習的に、各パスはあなたが所有する一意のプレフィックスで始まるように配置されます。 例えば、Google内部で使用されるパスはすべて'google'で始まり、 リモートリポジトリを示すパスはコードへのパス、例えば'github.com/user/repo'で始まります。

プログラム内のパッケージは一意のパッケージ名を持つ必要はありませんが、 特別な意味を持つ2つの予約済みのパッケージ名があります。 名前mainはコマンドを示し、ライブラリではありません。 コマンドはバイナリにビルドされ、インポートすることはできません。 名前documentationは、ディレクトリ内の非Goプログラムのドキュメンテーションを示します。 パッケージdocumentation内のファイルはgoコマンドによって無視されます。

特別なケースとして、パッケージリストが単一のディレクトリからの.goファイルのリストである場合、 コマンドはそれらのファイルだけから構成される単一の合成パッケージに適用され、 それらのファイル内のビルド制約は無視され、ディレクトリ内の他のファイルも無視されます。

"."または"_"で始まるディレクトリ名とファイル名は、goツールによって無視されます。 また、"testdata"という名前のディレクトリも無視されます。

非公開コードのダウンロード設定

goコマンドはデフォルトで、公開Goモジュールミラーのproxy.golang.orgからモジュールをダウンロードします。 また、ソースに関係なくダウンロードしたモジュールを公開Goチェックサムデータベースのsum.golang.orgで検証するようにデフォルト設定されています。 これらのデフォルトは、公開されているソースコードに対してはうまく機能します。

GOPRIVATE環境変数は、goコマンドがプライベート（公開されていない）とみなすモジュールを制御し、 そのためプロキシやチェックサムデータベースを使用しないようにします。 この変数は、モジュールパスのプレフィックスのglobパターン（Goのpath.Matchの構文）のカンマ区切りのリストです。 例えば、

GOPRIVATE=*.corp.example.com,rsc.io/private

は、goコマンドがgit.corp.example.com/xyzzy、rsc.io/private、rsc.io/private/quuxなど、 いずれかのパターンに一致するパスプレフィックスを持つ任意のモジュールをプライベートとして扱うようにします。

モジュールのダウンロードと検証を細かく制御するために、GONOPROXYとGONOSUMDB環境変数は同じ種類のglobリストを受け入れ、 プロキシとチェックサムデータベースを使用するかどうかの具体的な決定についてGOPRIVATEを上書きします。

例えば、会社がプライベートモジュールを提供するモジュールプロキシを運用している場合、 ユーザーはgoを次のように設定します：

GOPRIVATE=*.corp.example.com
GOPROXY=proxy.example.com
GONOPROXY=none

GOPRIVATE変数はまた、GOVCS変数の"public"と"private"のパターンを定義するために使用されます。 その使用法については、'go help vcs'を参照してください。その使用法では、GOPRIVATEはGOPATHモードでも適用されます。 その場合、それはモジュールパスではなくインポートパスに一致します。

'go env -w'コマンド（'go help env'を参照）は、これらの変数を将来のgoコマンドの呼び出しに設定するために使用できます。

詳細は、https://golang.org/ref/mod#private-modules を参照してください。

テストフラグ

'go test'コマンドは、'go test'自体に適用されるフラグと、 結果として得られるテストバイナリに適用されるフラグの両方を取ります。

フラグのいくつかはプロファイリングを制御し、"go tool pprof"に適した実行プロファイルを書き出します。 "go tool pprof -h"を実行して、詳細情報を得てください。 pprofの--alloc_space、--alloc_objects、および--show_bytesオプションは、情報がどのように表示されるかを制御します。

'go test'コマンドは以下のフラグを認識し、 任意のテストの実行を制御します：

-bench regexp
    正規表現に一致するベンチマークのみを実行します。
    デフォルトでは、ベンチマークは実行されません。
    すべてのベンチマークを実行するには、'-bench .'または'-bench=.'を使用します。
    正規表現は、括弧で囲まれていないスラッシュ(/)文字で分割され、
    一連の正規表現になり、ベンチマークの識別子の各部分は、
    シーケンス内の対応する要素と一致する必要があります（もしあれば）。
    マッチの可能な親は、サブベンチマークを識別するためにb.N=1で実行されます。
    例えば、-bench=X/Yが与えられた場合、Xに一致するトップレベルのベンチマークは
    b.N=1で実行され、Yに一致する任意のサブベンチマークを見つけるために、
    それらは完全に実行されます。

-benchtime t
    各ベンチマークのイテレーションをt（time.Durationとして指定）の時間だけ実行します
    （例えば、-benchtime 1h30s）。
    デフォルトは1秒（1s）です。
    特別な構文Nxは、ベンチマークをN回実行することを意味します
    （例えば、-benchtime 100x）。

-count n
    各テスト、ベンチマーク、およびfuzz seedをn回実行します（デフォルトは1）。
    -cpuが設定されている場合、GOMAXPROCSの値ごとにn回実行します。
    例は常に一度だけ実行されます。-countは-fuzzによってマッチした
    fuzzテストには適用されません。

-cover
    カバレッジ分析を有効にします。
    カバレッジはコンパイル前にソースコードに注釈を付けることで動作するため、
    カバレッジが有効な状態でのコンパイルエラーやテスト失敗は、
    元のソースと一致しない行番号を報告する可能性があります。

-covermode set,count,atomic
    テスト対象のパッケージのカバレッジ分析のモードを設定します。
    デフォルトは"set"ですが、-raceが有効な場合は"atomic"になります。
    値：
	set: bool: このステートメントは実行されますか？
	count: int: このステートメントは何回実行されますか？
	atomic: int: countと同じですが、マルチスレッドのテストで正確です。
		大幅にコストがかかります。
    -coverを設定します。

-coverpkg pattern1,pattern2,pattern3
    各テストで、パターンに一致するパッケージにカバレッジ分析を適用します。
    デフォルトでは、各テストはテスト対象のパッケージのみを分析します。
    パッケージパターンの説明については、'go help packages'を参照してください。
    -coverを設定します。

-cpu 1,2,4
    テスト、ベンチマーク、またはfuzzテストを実行するためのGOMAXPROCS値のリストを指定します。
    デフォルトは現在のGOMAXPROCSの値です。-cpuは-fuzzによってマッチしたfuzzテストには適用されません。

-failfast
    最初のテスト失敗後、新しいテストを開始しない。

-fullpath
    エラーメッセージで完全なファイル名を表示します。

-fuzz regexp
    正規表現にマッチするfuzzテストを実行します。指定された場合、
    コマンドライン引数はメインモジュール内の正確に1つのパッケージと一致し、
    regexpはそのパッケージ内の正確に1つのfuzzテストと一致する必要があります。
    ファジングは、テスト、ベンチマーク、他のfuzzテストのシードコーパス、
    および例が完了した後に行われます。詳細は、テストパッケージのドキュメンテーションの
    Fuzzingセクションを参照してください。

-fuzztime t
    ファジング中にfuzzターゲットのイテレーションをt（time.Durationとして指定）の時間だけ実行します
    （例えば、-fuzztime 1h30s）。
	デフォルトは永遠に実行することです。
    特別な構文Nxは、fuzzターゲットをN回実行することを意味します
    （例えば、-fuzztime 1000x）。

-fuzzminimizetime t
    各最小化試行中にfuzzターゲットのイテレーションをt（time.Durationとして指定）の時間だけ実行します
    （例えば、-fuzzminimizetime 30s）。
	デフォルトは60sです。
    特別な構文Nxは、fuzzターゲットをN回実行することを意味します
    （例えば、-fuzzminimizetime 100x）。

-json
    JSON形式で詳細な出力とテスト結果をログに記録します。これは、
    マシンが読み取れる形式で-vフラグと同じ情報を提供します。

-list regexp
    正規表現に一致するテスト、ベンチマーク、fuzzテスト、または例をリストします。
    テスト、ベンチマーク、fuzzテスト、または例は実行されません。
    これはトップレベルのテストのみをリストします。サブテストやサブベンチマークは
    表示されません。

-parallel n
    t.Parallelを呼び出すテスト関数の並列実行を許可し、
    シードコーパスを実行する際にt.Parallelを呼び出すfuzzターゲットを許可します。
    このフラグの値は、同時に実行するテストの最大数です。
    ファジング中、このフラグの値は、T.Parallelが呼び出されるかどうかに関係なく、
    同時にfuzz関数を呼び出すことができるサブプロセスの最大数です。
    デフォルトでは、-parallelはGOMAXPROCSの値に設定されています。
    -parallelをGOMAXPROCSよりも高い値に設定すると、特にファジング時に、
    CPUの競合によりパフォーマンスが低下する可能性があります。
    -parallelは単一のテストバイナリ内でのみ適用されることに注意してください。
    'go test'コマンドは、-pフラグの設定に従って、異なるパッケージのテストを
    並行して実行することもあります（'go help build'を参照）。

-run regexp
    正規表現に一致するテスト、例、およびfuzzテストのみを実行します。
    テストの場合、正規表現は括弧で囲まれていないスラッシュ(/)文字で分割され、
    一連の正規表現になり、テストの識別子の各部分は、
    シーケンス内の対応する要素と一致する必要があります（もしあれば）。
    マッチの可能な親も実行されるため、-run=X/YはXに一致するすべてのテストを
    マッチさせ、実行し、結果を報告します。これには、Yに一致するサブテストがないものも含まれます。
    なぜなら、それらのサブテストを探すためには、それらを実行する必要があるからです。
    -skipも参照してください。

-short
    長時間実行されるテストに対して、その実行時間を短縮するよう指示します。
    デフォルトではオフですが、all.bashの間に設定されるため、
    Goツリーのインストールは、健全性チェックを実行できますが、
    徹底的なテストを実行する時間を費やすことはありません。

-shuffle off,on,N
    テストとベンチマークの実行順序をランダムにします。
    デフォルトではオフです。-shuffleがonに設定されている場合、
    システムクロックを使用してランダム化をシードします。-shuffleが
    整数Nに設定されている場合、Nはシード値として使用されます。
    どちらの場合も、再現性のためにシードが報告されます。

-skip regexp
    正規表現に一致しないテスト、例、fuzzテスト、およびベンチマークのみを実行します。
    -runと-benchのように、テストとベンチマークの場合、正規表現は括弧で囲まれていない
    スラッシュ(/)文字で分割され、一連の正規表現になり、テストの識別子の各部分は、
    シーケンス内の対応する要素と一致する必要があります（もしあれば）。

-timeout d
    テストバイナリがdより長く実行される場合、パニックします。
    dが0の場合、タイムアウトは無効になります。
    デフォルトは10分（10m）です。

-v
    冗長な出力：実行されるすべてのテストをログに記録します。また、テストが成功しても
    LogとLogfの呼び出しからすべてのテキストを印刷します。

-vet list
    "go test"中の"go vet"の呼び出しを設定して、カンマ区切りのvetチェックのリストを使用します。
    リストが空の場合、"go test"は、常に対処する価値があると考えられるチェックのキュレーションされたリストで"go vet"を実行します。
    リストが"off"の場合、"go test"は"go vet"を全く実行しません。

以下のフラグも 'go test' によって認識され、実行中のテストをプロファイルするために使用できます:

-benchmem
    ベンチマークのメモリ割り当て統計を出力します。

-blockprofile block.out
    すべてのテストが完了したときに、指定されたファイルにゴルーチンのブロックプロファイルを書き込みます。
    -cと同様にテストバイナリを書き込みます。

-blockprofilerate n
    runtime.SetBlockProfileRateをnで呼び出すことで、ゴルーチンのブロックプロファイルの詳細を制御します。
    'go doc runtime.SetBlockProfileRate'を参照してください。
    プロファイラは、プログラムがブロックされている間、平均してnナノ秒ごとに1つのブロックイベントをサンプリングすることを目指します。
    デフォルトでは、-test.blockprofileがこのフラグなしで設定されている場合、すべてのブロックイベントが記録されます。
    これは-test.blockprofilerate=1と同等です。

-coverprofile cover.out
    すべてのテストが通過した後に、カバレッジプロファイルをファイルに書き込みます。
    -coverを設定します。

-cpuprofile cpu.out
    終了する前に、指定されたファイルにCPUプロファイルを書き込みます。
    -cと同様にテストバイナリを書き込みます。

-memprofile mem.out
    すべてのテストが通過した後に、割り当てプロファイルをファイルに書き込みます。
    -cと同様にテストバイナリを書き込みます。

-memprofilerate n
    runtime.MemProfileRateを設定することで、より精密（かつ高価）なメモリ割り当てプロファイルを有効にします。
    'go doc runtime.MemProfileRate'を参照してください。
    すべてのメモリ割り当てをプロファイルするには、-test.memprofilerate=1を使用します。

-mutexprofile mutex.out
    すべてのテストが完了したときに、指定されたファイルにミューテックス競合プロファイルを書き込みます。
    -cと同様にテストバイナリを書き込みます。

-mutexprofilefraction n
    競合するミューテックスを保持するゴルーチンのスタックトレースの1/nをサンプリングします。

-outputdir directory
    プロファイリングからの出力ファイルを指定されたディレクトリに配置します。
    デフォルトでは、"go test"が実行されているディレクトリです。

-trace trace.out
    終了する前に、指定されたファイルに実行トレースを書き込みます。

これらのフラグはすべて、-test.vのように、オプションの'test.'プレフィックス付きでも認識されます。 ただし、生成されたテストバイナリ（'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'がテストバイナリを実行するとき、それは対応するパッケージのソースコードディレクトリ内から行います。 テストによっては、生成されたテストバイナリを直接呼び出すときにも同様にする必要があるかもしれません。 そのディレクトリはモジュールキャッシュ内に位置している可能性があり、 それは読み取り専用であり、チェックサムによって検証されるため、 テストはユーザーが明示的に要求した場合（-fuzzフラグのように、 失敗をtestdata/fuzzに書き込む場合など）を除き、 それまたはモジュール内の他の任意のディレクトリに書き込んではなりません。

コマンドラインのパッケージリストが存在する場合、それは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と2つ目の-vはテストバイナリにそのまま渡され、goコマンド自体には影響を与えません。 2つ目の例では、引数mathはテストバイナリに渡され、パッケージリストとして解釈される代わりになります。

テスト関数

'go test'コマンドは、テスト対象のパッケージに対応する"*_test.go"ファイル内にテスト、ベンチマーク、および例示関数を見つけることを期待しています。

テスト関数はTestXxxという名前のものであり（ここで、Xxxは小文字で始まらない）、以下のシグネチャを持つべきです。

func TestXxx(t *testing.T) { ... }

ベンチマーク関数はBenchmarkXxxという名前のものであり、以下のシグネチャを持つべきです。

func BenchmarkXxx(b *testing.B) { ... }

ファズテストはFuzzXxxという名前のものであり、以下のシグネチャを持つべきです。

func FuzzXxx(f *testing.F) { ... }

例示関数はテスト関数と似ていますが、成功や失敗を報告するために*testing.Tを使用する代わりに、 出力をos.Stdoutに印刷します。 関数内の最後のコメントが"Output:"で始まる場合、出力はコメントと完全に比較されます（下記の例を参照）。 最後のコメントが"Unordered 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
}

テストファイル全体が例として提示されます。それは単一の 例示関数、少なくとも1つの他の関数、型、変数、または定数 宣言を含み、テスト、ベンチマーク、またはファズテストがない場合です。

詳細情報については、testingパッケージのドキュメンテーションを参照してください。

GOVCSでバージョン管理を制御する

'go get'コマンドは、gitのようなバージョン管理コマンドを実行して、インポートされたコードをダウンロードすることができます。 この機能は、任意のサーバーからコードをインポートできる分散型のGoパッケージエコシステムにとって重要ですが、 悪意のあるサーバーが呼び出されたバージョン管理コマンドを使って意図しないコードを実行する方法を見つけた場合、 セキュリティ問題にもなります。

機能とセキュリティの懸念をバランス良く取るために、'go get'コマンドはデフォルトで公開サーバーからコードをダウンロードするために gitとhgのみを使用します。 しかし、プライベートサーバーからコードをダウンロードするためには、任意の既知のバージョン管理システム（bzr、fossil、git、hg、svn）を使用します。 プライベートサーバーとは、GOPRIVATE変数（'go help private'を参照）に一致するパッケージをホスティングするサーバーを指します。 GitとMercurialのみを許可する背後にある理由は、これらの2つのシステムが、信頼できないサーバーのクライアントとして実行される問題に最も注目されているからです。 対照的に、Bazaar、Fossil、およびSubversionは主に信頼できる、認証された環境で使用されており、攻撃面としてはあまり注目されていません。

バージョン管理コマンドの制限は、直接バージョン管理アクセスを使用してコードをダウンロードするときにのみ適用されます。 プロキシからモジュールをダウンロードするとき、'go get'は代わりに常に許可されているプロキシプロトコルを使用します。 デフォルトでは、'go get'コマンドは公開パッケージに対してGoモジュールミラー（proxy.golang.org）を使用し、 プライベートパッケージまたはミラーが公開パッケージを提供を拒否するとき（通常は法的な理由で）だけバージョン管理にフォールバックします。 したがって、クライアントはデフォルトでBazaar、Fossil、またはSubversionリポジトリから提供される公開コードにアクセスできます。 なぜなら、それらのダウンロードはGoモジュールミラーを使用し、カスタムサンドボックスを使用してバージョン管理コマンドを実行するセキュリティリスクを引き受けるからです。

GOVCS変数は、特定のパッケージ（モジュールまたはインポートパスで識別）の許可されたバージョン管理システムを変更するために使用できます。 GOVCS変数は、モジュール対応モードとGOPATHモードの両方でパッケージをビルドするときに適用されます。 モジュールを使用するとき、パターンはモジュールパスに対して一致します。 GOPATHを使用するとき、パターンはバージョン管理リポジトリのルートに対応するインポートパスに一致します。

GOVCS設定の一般的な形式は、カンマで区切られたpattern:vcslistルールのリストです。 パターンは、モジュールまたはインポートパスの1つ以上の先頭要素と一致する必要があるグロブパターンです。 vcslistは、許可されたバージョン管理コマンドのパイプで区切られたリストであり、または"all"は任意の既知のコマンドの使用を許可し、 "off"はすべてのコマンドの使用を禁止します。 モジュールがvcslist "off"のパターンと一致する場合でも、元のサーバーが"mod"スキームを使用すると、 goコマンドがモジュールをGOPROXYプロトコルを使用してダウンロードするよう指示するため、それでもダウンロードされる可能性があります。 リスト内の最初に一致するパターンが適用されます、後のパターンも一致するかもしれません。

例えば、以下を考えてみましょう：

GOVCS=github.com:git,evil.com:off,*:git|hg

この設定では、モジュールまたはインポートパスが github.com/で始まるコードはgitのみを使用できます。evil.comのパスはバージョン管理コマンドを使用できません。 そして、他のすべてのパス（*はすべてに一致）はgitまたはhgのみを使用できます。

特別なパターン"public"と"private"は、公開および非公開のモジュールまたはインポートパスに一致します。 パスがGOPRIVATE変数と一致する場合、そのパスは非公開です。それ以外の場合は公開です。

GOVCS変数のルールが特定のモジュールまたはインポートパスと一致しない場合、 'go get'コマンドはデフォルトのルールを適用します。これは現在、GOVCS表記法で'public:git|hg,private:all'と要約できます。

任意のパッケージに対して任意のバージョン管理システムを無制限に使用するには、以下を使用します：

GOVCS=*:all

バージョン管理のすべての使用を無効にするには、以下を使用します：

GOVCS=*:off

'go env -w'コマンド（'go help env'を参照）を使用して、将来のgoコマンド呼び出しのためのGOVCS変数を設定できます。