（2018年第二季度：
请注意，对于 vgo项目
，GOPATH可能最终不赞成使用基于项目的工作流。这样可以避免GOPATH两年前我在下面提出的基于手动项目的建议）

使用Go 1.11（2018年8月）， GOPATH
可以是可选的，带有modules。

VSCode越来越支持它：

• vscode-go / issue 1532
• “ Visual Studio Code中的Go模块支持 ”

2016年6月：您不必 仅
依赖一个GOPATH（即一个工作区）。

我的全部GOPATH内容包括：

• 一个全球性的路径（所有公用事业喜欢goimports），github.com/smartystreets/goconvey…），在$HOME/go例如，
• 本地路径（我当前的项目），在我的地方src，pkg并且bin会。

这是两条路径：

export GOPATH=/path/to/myproject:$HOME/go

为我的所有项目都拥有一个$ GOPATH目录是不安全的，因此所有必需的第三方库都安装在同一个lib目录中，并且每当我编译项目时，它都将使用所需的库。

在实践中这不好吗？为什么？

我不喜欢这种做法，因为不同的项目可能需要同一个库的不同 版本 。
这就是为什么GOPATH每个项目都有一个，我的构建脚本（随项目版本化）为我设置的原因。

当我克隆我的go项目时，我：

• 将我GOPATH设置为该go项目（本地路径，将安装该项目所需的第三方库，并将其移至vendor文件夹中），
• 与该路径进行符号链接<myproject>/src/<myproject> -> ../..，因为GOPATH手段go希望找到myprojectin 的来源src/<apackage>。

该组织：

• 保持兼容go get，
• 确保默认情况下，将我需要的所有特定依赖项安装在我的项目文件夹中，而不是在global中存在的大量全局库/实用程序中丢失GOPATH。

我有：

myproject
   mysource.go
   apackage
     othersource.go
   src
     myproject -> ../..
     vendor
        third-party packages

在Windows上，典型的构建脚本为：

λ more b.bat
@echo off
setlocal EnableDelayedExpansion
if not defined GOROOT (
        echo Environment variable GOROOT must be defined, with %%GOROOT%%\bin\go.exe
        exit /b 1
)

set PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
set PATH=%PATH%;%GOROOT%/bin
set GOPATH=%~dp0;%HOME%/go

set prjname=%GOPATH:~0,-1%
for %%i in ("%prjname%") do set "prjname=%%~ni"
rem echo prjname='%prjname%'

if not exist src (
        mkdir src
)
if not exist src\%prjname% (
        mklink /J src\%prjname% %GOPATH%
)

pushd %~dp0
cd src\%prjname%
rem cd
go install
popd
endlocal

克隆我的go项目的任何人都只需键入“ b”。