Go语言环境变量优先级由go命令解析逻辑决定，非语言特性：按命令行参数→用户环境变量→系统环境变量→内置默认值顺序读取，GOPROXY匹配顺序为GOPRIVATE→GONOPROXY→GOPROXY，direct为必选兜底策略。
Go 语言环境变量优先级不是语言特性，而是工具链行为
Go 本身不定义任何环境变量优先级规则。你看到的 GOPATH、GOROOT、GOPROXY 等变量生效顺序，完全由 go 命令自身解析逻辑决定，不是 runtime 或编译器强制行为。
比如 go env 输出的值，是 go 工具链按固定顺序读取：命令行参数 → 用户环境变量 → 系统环境变量 → 内置默认值。这个顺序写死在源码里，无法通过代码修改。
-
GOPROXY会先查GOENV指向的配置文件（如$HOME/.config/go/env），再查环境变量，最后 fallback 到默认值https://proxy.golang.org,direct -
GOPATH如果没设，go 会用$HOME/go；但如果你在 shell 启动脚本里用export GOPATH=~/mygopath，它就覆盖默认值 -
GOROOT一般不用手动设——msi 安装器已写入注册表或/usr/local/go，只有多版本共存时才需显式指定
go get 和模块代理的优先级怎么控制
go get 的模块拉取路径优先级，取决于 GOPROXY 和 GOPRIVATE 的组合逻辑，不是简单“谁在前面谁生效”。
真实行为是：go 把 GOPROXY 拆成逗号分隔的列表，依次尝试每个代理；遇到第一个返回 200 的就停止；但若请求的 module 在 GOPRIVATE 列表中匹配（支持 glob），则跳过所有 proxy，直连 git 服务器。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
GOPROXY=https://goproxy.cn,https://proxy.golang.org+GOPRIVATE=git.mycompany.com→ 私有域名请求不会走 proxy，但拼写不匹配（比如写成mycompany.com）就会漏掉 - 正确写法：
GOPRIVATE=*.mycompany.com,github.com/my/private，注意通配符必须带*，且不能有空格 -
go env -w GOPROXY=https://goproxy.cn,direct中的direct是兜底项，表示“如果前面都失败，就自己去 git 拉”，不是“跳过 proxy”
viper 配置里的环境变量优先级和 Go 工具链无关
很多人混淆了两类环境变量：一类是给 go 命令用的（如 GOPROXY），另一类是给你的业务程序用的（如 APP_PORT）。viper 只管后者，且它的优先级完全由你调用顺序控制。
viper 默认把环境变量源加在最低优先级，所以 viper.AutomaticEnv() 单独调用几乎没用。真正起效的前提是：
- 先调
viper.ReadInConfig()加载 config.yaml，让内存里有 key（如server.port） - 再调
viper.SetEnvPrefix("APP")和viper.AutomaticEnv()，否则APP_SERVER_PORT不会映射到server.port - 最后一步常被忽略：
viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))，否则server.port找不到SERVER.PORT（默认只转.为_，但不处理大小写）
Makefile 或启动脚本里设置环境变量的坑
在 Makefile 里写 run-prod: APP_ENV=prod go run main.go 是无效的——这个赋值只对当前 make rule 的 shell 生效，go run 子进程拿不到。
正确做法是用 env 命令前缀或导出变量：
run-prod: env APP_ENV=prod go run main.go- 或者在 shell 中：
export APP_ENV=prod && go run main.go - 测试时尤其要注意：
go test不继承父 shell 的APP_ENV，得用os.Setenv在TestMain里手动设
环境变量的生效点很细碎：shell 启动方式（login/non-login）、是否 source 过 profile、go 工具链版本差异，都可能让同一个变量在不同机器上表现不一致。别依赖“应该能读到”，每次都要用 os.Getenv 显式检查。
