GOROOT: The path of the root directory of the Go language installation, that is, the installation path of the GO language.
GOPATH: Path to several workspace directories. It is our own defined workspace.
GOBIN: The path to the executable file (executable file) generated by the GO program
Is there any point in setting GOPATH?
GOPATH can be simply understood as the working directory of the Go language. Its value is the path of a directory or multiple directory paths. Each directory represents a workspace of the Go language.
The workspace places the source code file (source file) of the Go language, as well as the archive file (archive file, ".a".exe) and the executable file (executable file) after installation (install). Each workspace will have three folders: src, pkg, and bin.
go
The source code of the Go language uses code packages as the basic organizational unit. In the file system, there is a one-to-one correspondence between code packages and directories. Just as directories can have subdirectories, code packages can also have subpackages. A code package can contain any number of source code files with the extension .go, and these source code files need to be declared to belong to the same code package. The name of the code package will generally be the same as the directory where the source code files are located. If the names are different, the code package name will prevail during the construction and installation process .
Each code package will have import paths. The import path of a code package is the path that other code needs to import when using the program entities in the package. Before actually using a program entity, we must first import the code package it is in. In the workspace, the import path of a code package is actually the relative path from the src subdirectory to the actual storage location of the package.
The organization of Go language source code is based on the environment variable GOPATH, workspace, src directory and code package as the main line. In general, the source code files of the Go language need to be stored in a code package (directory) under the src directory in a workspace (directory) contained in the environment variable GOPATH.
go set domestic proxy
go env -w GOPROXY=https://goproxy.cn
goget-deprecated
After version 1.17.1, the go get command can no longer be used, and all have been changed to the go install command.
“go install pkg@version”代替
go install github.com/go-sql-driver/mysql@latest
go install github.com/jmoiron/sqlx@latest
gobuild
1. Add the flag -x when running the go build command, so that you can see the specific operations performed by the go build command. You can also add the flag -n, so that you can only view specific operations without executing them.
2. Add the flag -v when running the go build command, so that you can see the name of the code package compiled by the go build command. It is useful when used with the -a flag.
1. In what order does the Go language search for dependent packages in multiple workspaces?
If a depends on b, and b depends on c, the c package will be searched first.
When looking for dependent packages, the GOROOT directory will be searched first. If no dependent package is found, then go to the workspace to find the corresponding package. Search in the workspace according to the order of settings, and start from the first one, search in turn, if found, do not continue to search, if not found, an error will be reported. go get will download the code package to the src directory, but only to the first workspace directory. In a Go language program, each package has a globally unique import path. A string similar to "github.com/xxxx/tem" in the import statement corresponds to the import path of the package. The specification of the Go language does not define what these strings mean or where the package comes from, they are interpreted by the build tools.
An import path represents one or more Go source files in a directory. In addition to the import path of the package, each package also has a package name. The package name is generally a short name (the package name is not required to be unique), and the package name is specified in the package declaration.
2. If there are code packages with the same import path in multiple workspaces, will there be conflicts?
There is no conflict, because if you find the required packages in order, you will not look back.