goos和goarch仅在当前go build进程生效，必须与命令同行设置（如goos=linux goarch=arm64 go build），export方式会污染shell环境；goroot/gopath由go启动时读取并缓存，修改后需重启shell或ide。
Go 环境变量不是设了就立刻全局生效的，关键看它在哪个进程生命周期里被读取——go 命令本身、你的 Go 程序、还是 IDE（如 VSCode）各自读取的是自己启动时继承的那一份。
GOOS 和 GOARCH 只影响当前 go build 进程，不改变系统全局状态
你执行 GOOS=linux GOARCH=arm64 go build，这两个变量只在这一次 go build 子进程中有效。它们不会写入 shell 环境，也不会影响后续命令或已运行的程序。
- 错误做法：在终端里先运行
export GOOS=linux，然后开另一个终端跑程序——新终端根本没继承这个变量 - 正确做法：要么把变量和
go build写在同一行（推荐），要么在构建脚本里用env包裹，例如env GOOS=linux GOARCH=arm64 go build -o app - 注意：
GOARM（用于 ARM32）必须显式设置，GOARCH=arm本身不自动推导浮点模式，漏设会导致运行时 panic
GOROOT 和 GOPATH 的值由 go 命令启动时确定，改完要重启 shell 或重新加载配置
go 命令在启动瞬间读取 GOROOT 和 GOPATH，之后全程缓存。即使你中途用 export 改了，正在运行的 go 进程、VSCode 的 Go 扩展、或者 Delve 调试器都不会感知。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 常见现象：修改
~/.zshrc后go env GOROOT仍显示旧路径——因为 shell 没重载，或 VSCode 是从桌面环境启动、压根没读你的 shell 配置 - 验证方式：在终端里直接运行
go env GOROOT，再在 VSCode 的集成终端里运行同一命令，两者结果可能不同 - 解决办法：改完配置后，关闭所有终端和 VSCode，再全新启动；或在 VSCode 设置里强制指定
"go.goroot"路径
Go 程序读不到 shell 的 export 变量，除非你显式传入或提前设置
你的 Go 代码调用 os.Getenv("PORT") 读的是进程启动时继承的环境变量副本。如果是在 IDE 里点“运行”，那副本来自 IDE 启动时的环境，和你在终端里 export PORT=8080 完全无关。
- 本地开发调试时，别依赖终端 export：改用
.env文件 +godotenv加载，或在 VSCode 的launch.json里配"env"字段 - Docker 场景下，
environment:在 docker-compose.yml 中定义的变量，只注入容器内进程，宿主机的export对它无效 - CI/CD 中，变量需在 runner 配置里声明（如 GitHub Actions 的
env:），不能靠run: export FOO=bar——那条命令结束后变量就丢了
GO111MODULE 和 GOPROXY 生效有隐式优先级，容易被忽略
GO111MODULE 默认是 on（Go 1.16+），但若当前目录有 vendor/ 且 GO111MODULE=auto，它会退化为 vendor 模式；GOPROXY 若设为 https://goproxy.cn,direct，遇到私有域名（如 git.corp.com）会 fallback 到 direct，但前提是 GOPRIVATE 已包含该域名，否则仍走代理并失败。
- 典型故障：
go mod download报错invalid version或超时——先检查go env GOPROXY GOPRIVATE，再确认GOPRIVATE是否匹配模块导入路径的前缀 -
GOINSECURE仅对 HTTP 协议仓库生效，对 HTTPS 仓库无效；若公司内部用自签名证书的 HTTPS 仓库，得配GOSUMDB=off或自定义GOSUMDB - 多项目共用一个 GOPROXY 缓存，但
GOMODCACHE是按模块路径隔离的，不用额外清理
最常被绕过的其实是「环境变量作用域」这个前提：它不是配置项，而是进程的输入快照。任何跳过进程重启、IDE 重载、或容器重建的操作，都只是在改幻灯片，不是改运行时。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
