go语言为什么这么依赖gopath这个环境变量

GOPATH是你的工作目录，对于项目文件而言，项目的结构和你的工作目录的结构有很大关系。

创新互联建站-专业网站定制、快速模板网站建设、高性价比罗田网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式罗田网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖罗田地区。费用合理售后完善，10年实体公司更值得信赖。

GOPATH路径下默认是有以下三个目录的，

1.src 存放源代码（比如：.go .c .h .s等）

2.pkg 编译后生成的文件（比如：.a）

3.bin 编译后生成的可执行文件（为了方便，可以把此目录加入到 $PATH 变量中，如果有多个gopath，那么使用${GOPATH//://bin:}/bin添加所有的bin目录）

golang的 GOPATH和vendor的搜索关系

golang的 GOPATH和vendor的搜索关系

项目只有一个包，即main包，没有引用其他的包(golang自带的系统包除外)。

然后设置GOPATH=path/to/goproject，再运行go build myproject，这样就可以在任何目录下面编译，编译生成的可执行文件就在编译所在的目录下，而不是包源文件所在的目录。

基本规则：

鉴于此，建议golang项目必须严格按照规范的目录结构组织，哪怕是前面这种自包含的项目。

基本规则：

如果一个包在vendor和GOPATH下面都存在那么谁会优先使用呢。

结论是：

包mydeps在vendor目录下面和GOPATH路径下面都存在了，那么main.go引用的时候只会引用vendor下面的mydeps(src/myproject/vendor/mydeps)，而忽略GOPATH下面的mydeps包(src/mydeps)。

前面提到GOPATH和PATH类似，可以包含多个路径，中间用分号隔开，go在搜索包的时候会按手续从前往后搜搜。那么vendor怎么处理层级关系呢。

规则是：

举例：

如果src/mydep/mydep1/mydep.go引用了myvendor1和myvendor，那是怎么搜索的呢

go语言设置时GOPATH和GOROOT有什么区别

可以简单理解为:

$GOPATH 是go的工程目录

/home/guest/gocode

├── bin

├── pkg

└── src

$GOROOT 是go的安装目录

/home/guest/tools/go

├── api

├── AUTHORS

├── bin

├── blog

├── CONTRIBUTING.md

├── CONTRIBUTORS

├── doc

├── favicon.ico

├── lib

├── LICENSE

├── misc

├── PATENTS

├── pkg

├── README.md

├── robots.txt

├── src

├── test

└── VERSION

分享标题：go语言gopath go语言开发为什么难找工作
转载来于：http://ybzwz.com/article/dohhgse.html