2019獨角獸企業重金招聘Python工程師標準>>>

GOROOT

golang安裝路徑。

GOPATH

官方解釋，請google。go工作環境中常常用到的一個很重要的環境變量（這種設計類似java）。具體用途：go命令常常需要用到的，如go run，go install， go get等。允許設置多個路徑，和各個系統環境多路徑設置一樣，windows用“;”，linux（mac）用“:”分隔。

在linux（Mac）下，為了方便，一般配置在~/.bash_profile中。

book:~?wukebing$?vi?~/.bash_profile??//編輯

book:~ wukebing$ source ~/.bash_profile //編輯完成后，使立即生效

例如：我的GOPATH設置（MAC下）

export?GOPATH=$HOME/workspace/go export?PATH=$PATH:${GOPATH//://bin:}/bin export?GOBIN=

其中，“export PATH=$PATH:${GOPATH//://bin:}/bin”為Linux（Mac）下把每個GOPATH下的bin都加入到PATH中。

當存在多個路徑時，好像優先采用第一個路徑。這個無關緊要了，只有需要的第三方包（庫）都能正確下載和使用就ok了。

GOBIN

go install編譯存放路徑。不允許設置多個路徑。可以為空。為空時則遵循“約定優于配置”原則，可執行文件放在各自GOPATH目錄的bin文件夾中（前提是：package main的main函數文件不能直接放到GOPATH的src下面。

go環境查看

用go env 可查看當前go環境變量。

GOPATH目錄結構

goWorkSpace??//?(goWorkSpace為GOPATH目錄)--?bin??//?golang編譯可執行文件存放路徑，可自動生成。--?pkg??//?golang編譯的.a中間文件存放路徑，可自動生成。--?src??//?源碼路徑。按照golang默認約定，go?run，go?install等命令的當前工作路徑（即在此路徑下執行上述命令）。

go目錄結構1:

project1?//?(project1添加到GOPATH目錄了)--?bin--?pkg--?src??--?models???????//?package--?controllers??//?package--?main.go??????//?package?main［注意，本文所有main.go均指包main的入口函數main所在文件］ ?project2?//?(project2添加到GOPATH目錄了)--?bin??????--?pkg??????--?src?????????--?models???????//?package?????????--?controllers??//?package?????????--?main.go??????//?package?main1234567

package main文件直接在GOPATH目錄到src下。

使用go build可以在src文件夾下編譯生成名為“src”的可執行文件。這是golang默認約定。一般我個人不怎么用這個命令。因為它會生成可執行文件在src目錄下面。

我一般用：go get 和 go install。

go get [main.go所在路徑]

參數 [main.go所在路徑]：可選。相對GOPATH/src路徑。 缺省是.(src自己)。可指定src下面的子文件夾路徑。?
go get會做2件事：1. 從遠程下載需要用到的包。2.執行go install。（從這里也可以看出golang處處為了簡潔而遵循的“約定優于配置”原則）

go install [main.go所在路徑]

參數 [main.go所在路徑]：可選。 相對GOPATH/src路徑。缺省是.(src自己)。可指定src下面的子文件夾。?
go install編譯生成名稱為[main.go父文件夾名]的可執行文件，放到GOBIN路徑下。當GOBIN為空時，默認約定是：生成的可執行文件放到GOPATH/bin文件夾中。產生的中間文件（.a）放在project/pkg中（沒有變化時，不重新生成.a）。

我們再看此go目錄結構1，執行go install（以及go get的第二階段go install）會報錯：

注意：如果不用額外方式改變環境變量(公司目前用的是sh腳本編譯)，是編譯不過的。報錯：can’t load package: package .: no buildable Go source files in?*

解決方法1：?
曾經我也因為這個錯誤感到迷惑，認為所有都環境變量都沒有問題。網上也沒怎么看到直接明確都解答。看了一些帖子后，觸類旁通，設置了GOBIN環境變量后解決。（好吧，我至今也沒有完整讀過英文官方文檔。這種默認約定，官方文檔上應該有。）

此解決方法有個弊端，多個project會導致多個GOPATH目錄。多個project下的目錄結構和包一致的話，直接編譯會導致編譯問題。因為go優先使用第一個GOPATH目錄，導致編譯沖突。（當然，你也可以每次手工或腳步修改GOPATH環境變量，感覺很麻煩。）不建議多個project直接設置到茫茫多的GOPATH中。當然有解決方法2，我認為是標準合理的解決方法，就是下面go目錄結構2了。

go目錄結構2:

goWorkSpace?????//?goWorkSpace為GOPATH目錄--?bin--?myApp1??//?編譯生成--?myApp2??//?編譯生成--?myApp3??//?編譯生成--?pkg--?src--?common?1--?common?2--?common?utils?...--?myApp1?????//?project1--?models--?controllers--?others--?main.go?--?myApp2?????//?project2--?models--?controllers--?others--?main.go?--?myApp3?????//?project3--?models--?controllers--?others--?main.go

一個solution里面的多個project或工具組件都并列放在GOPATH的src下，如myApp1，myApp2，myApp3，common utils。?
這時，GOBIN可以為空，編譯時，可以如下：?
go install myApp1 或 go get myApp1?
go install myApp2 或 go get myApp2?
go install myApp3 或 go get myApp3

這時才是大家都認為的，把可執行程序myApp1、myApp2、myApp3生成在goWorkSpace/bin下面。多個GOPATH也就有了上面的“把每個GOPATH下的bin都加入到PATH中”。

也可以設置GOBIN，而且這時，由于可執行文件名稱不同，也不大容易產生覆蓋（需要避免的時多個GOPATH用相同的“myApp”project名稱。）

具體的還是看個人喜好和實際情況。我個人本地的環境大致是：

dir??????--?goWorkSpace1????//?主要是為了區分自己的鼓搗的一些東西和工作上的項目--?goWorkSpace2--?bin--?pkg--?src??????????????????--?myApp1--?.git--?models--?controllers--?main.go?--?myApp2--?.git--?models--?controllers--?main.go?--?myApp3--?.git--?models--?controllers--?main.go

也就是我本地是有多個GOPATH路徑的dir/goWorkSpace1、dir/goWorkSpace2。?
注意：GOPATH目錄和GOPATH下的src不應該添加到源代碼管理中，而是各個project目錄myApp1、myApp2、myApp3各自時獨立的進行源代碼管理

我一般不設置GOBIN，把每個GOPATH下的bin都加入到PATH中。

轉載于:https://my.oschina.net/ethantonylam/blog/631750

總結

以上是生活随笔為你收集整理的GOROOT、GOPATH、GOBIN、project目录的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。