共计 1820 个字符，预计需要花费 5 分钟才能阅读完成。
大家好，我是煎鱼。
不晓得大家平时在调整 Go 环境变量是怎么设置的呢，还是说都用默认配置，又或是间接走 IDE 设置？
Go 环境变量倒退历程
像以前最早时，有的同学是关上 ~/.zshrc，一番 vim 操作，设置好 export GO111MODULE=on。最初再 source 一下。尽管简略，其实也是有好几个步骤的：
$ vi ~/.zshrc
$ export GO111MODULE=on
$ source ~/.zshrc 到了近年，Go 反对应用 go env -w 去设置对应的 Go 环境变量：
$ go env -w GO111MODULE=on 默认写入的门路是：filepath.Join(os.UserConfigDir(), "go/env")。对应不同的操作系统：
- MacOS：
$HOME/Library/Application Support/go/env。 - Linux：
$HOME/.config/go/env。
通过几年演进，Go 环境变量的设置逐步变得更不便。网上的教程、博客也纷纷扭转了写法。
这是截至目前的 Go 环境变量的历程。
Go1.21 go.env 诞生
不太好的中央
大家会发现，Go 当初的环境变量是越来越多了 … 如果都是用 go env -w 缓缓的就会越积攒越多，配置也就变得复杂了起来。
另外较为辣手的还有不同的 Go 我的项目之间的所需配置可能不太一样，产生穿插影响。也是一个影响点。
这让我想起了 Python 以前没有虚拟环境时的苦楚。Go 像是在 GO111MODULE 环境变量，会默认应用 auto 来躲避这个问题。会相较之轻微许多。
无论是轻还是重，问题还是存在的。
引入改良措施
因而在 Go1.21 这个新版本起，将会以用户设置的 $GOROOT/go.env 为更高优先级，会笼罩默认的设置。
既有的 GOPROXY、GOSUMDB 配置将会移动到 go.env 文件中，文件内容如下：
GOPROXY=https://proxy.golang.org,direct
GOSUMDB=sum.golang.org
GOTOOLCHAIN=auto
...有了 go.env 文件后，后续就能够应用他来代替默认变量或手动设置的步骤了。
有些瑕疵点
目前 Go1.21 只是引入了 $GOROOT/go.env 这一个全局的 ENV 配置文件。看着也有些瑕疵。为什么？
一般来讲要做残缺，应该要做到模块（go.mod）的级别，也就是每个 Go 利用有一个 go.env，这样子才可能齐全的实现我的项目（模块）级别的隔离。
但很惋惜，Go 新版本这次把这个局部给临时放弃了。因为每个模块引入 go.env 会波及太多的太多重大问题。
例如：
- 为什么引入一个独自的文件（go.env）而不是扩大 go.work？
- 在模块的 go.env 中是否容许所有的 Go 环境变量？
- 是否有一个选项来禁用模块的 go.env？或者这个新的 go.env 应该被默认疏忽？
- GoEnv 的具体含意？
- 须要一些工具？帮忙用户调试，通知他们最终取得的 Go 环境变量的过程和来自哪里，因为当初有太多的路径了。
- …
相同引入 $GOROOT/go.env 会更加明确和没什么争议，毕竟还是局限于既有体系下的全局配置源的新增反对。
综合来看，最初 Russ Cox 迅速躺平，勾销了模块（go.mod）级别的 go.env 反对。承受了此次提案的调整。
总结
各个编程语言的配置项和依赖治理始终是一大心魔，前有 Python3 应用 venv（虚拟环境）来解决。后有 Go，先是 godep，接着靠 Russ Cox 据理力争推 Go modules（go.mod）来解决依赖治理。
接下来就是 Go 的配置项的逐渐调整了，这个阻力绝对于依赖治理小许多。置信不须要太久，各模块很快就会容许有本人的 go.env 文件，来实现配置隔离。
大家能够继续关注！先从 $GOROOT/go.env 开始跟进。
文章继续更新，能够微信搜【脑子进煎鱼了】浏览，本文 GitHub github.com/eddycjy/blog 已收录，学习 Go 语言能够看 Go 学习地图和路线，欢送 Star 催更。
Go 图书系列
- Go 语言入门系列：初探 Go 我的项目实战
- Go 语言编程之旅：深刻用 Go 做我的项目
- Go 语言设计哲学：理解 Go 的为什么和设计思考
- Go 语言进阶之旅：进一步深刻 Go 源码
举荐浏览
- Go1.21 速览：新内置函数 clear、min、max 和新规范库包 cmp！
- Go1.21 速览：过了一年半，slices、maps 泛型库终于要退出规范库。。。
- Go1.21 速览：Go 终于打算进一步反对 WebAssembly 了。。。
