Understanding GOPATH and GOROOT in golang

Understanding GOPATH and GOROOT in golang

Project management in the Go language depends on the settings of the GOPATH and GOROOT environment variables.

We need to add the directory path of the workspace to the environment variable GOPATH. Otherwise, even in the same workspace, the absolute code package path cannot be called between codes.

In the actual development environment, there can be only one workspace or multiple workspaces, and the directory paths of these workspaces need to be added to GOPATH. As with GOROOT, we should make sure that GOPATH is always valid.


  • Do not include the root directory of the Go language in GOPATH, in order to strictly separate the workspace of the Go language itself from the user’s workspace.
  • Get the command go get through the code in the Go tool, you can download the source code of the specified project to the first workspace we set in GOPATH, and complete the compilation and installation in it.

source file

There are three types of Go source files, namely command source files, library source files, and test source files.

command source file

A source code file is a command source file if it is declared to belong to the main code package, and the code of the file contains a main function declared with no arguments and a result declaration . The command source file can be directly started and run through the go run command.

All source code files in the same code package must have the same name of the code package to which they belong. If the command source file and the library source file are in the same code package, the go build and go install commands cannot be executed correctly in that package. In other words, these source files will not be able to be compiled and installed by conventional means.

Therefore, command source files are usually placed in a separate code package. This is reasonable and necessary because there is usually only one startup entry for a program module or software.

There can be multiple command source files in the same code package, which can be run separately through the go run command, but this will prevent the go build and go install commands from compiling and installing the code package. Therefore, we should not put multiple command source files in the same code package.

When there is only one command source file in the code package, execute the go build command in the directory where the file is located, and an executable file with the same name as the directory can be generated in the directory; and if you use go install, you can run the current work The corresponding executable file is generated in the bin directory of the area.

It should be noted that only when the environment variable GOPATH contains only the directory path of one workspace, the go install command will install the command source file into the bin directory of the current workspace; otherwise, executing the go install command like this will fail. . At this point, the environment variable GOBIN must be set, and the value of the environment variable is the path of a directory used to store all executable files generated by installing the Go command source files.

library source file

Usually, the package name declared in the library source code file will be the same as the code package (directory) name to which it directly belongs, and the library source code file does not contain the main function declared with no parameters and no result declaration.

The archive files generated when installing the library source files are stored in the pkg directory of the current workspace.

Test source files

The test source code file is a special library file that can run all the test source code files under the current code package by executing the go test command. There are two sufficient conditions for becoming a test source file, as follows:

  • The filename needs to end with _test.go.
  • The file needs to contain at least one function whose name starts with Test or Benchmark and has a parameter of type *testing.T or *testing.B.
  • testing.T and testing.B are two struct types. And *testing.T and *testing.B are the pointer types of the first two respectively. They are required for functional testing and benchmarking respectively.