goroot是go安装根目录，负责提供编译器、标准库等工具链；gopath在go 1.16+仅控制go install输出路径（$gopath/bin），不再影响依赖管理，因模块模式已默认启用。
GOROOT 和 GOPATH 到底管什么？
很多人装完 Go 就开始写 main.go，但一遇到 go build 报错或 go install 找不到命令，才发现环境变量不是“设了就灵”。GOROOT 是 Go 工具链的根目录（比如 /usr/local/go），它只影响 go 命令本身从哪加载编译器、链接器等二进制文件；GOPATH 在 Go 1.16 之前是默认工作区路径，决定 src、pkg、bin 三目录位置——但现在它**仅在非 module 模式下生效**，且 go mod 启用后，GOPATH 对依赖管理已基本无影响，只还控制 go install 安装到哪（即 $GOPATH/bin）。
为什么 go env -w GO111MODULE=on 不一定管用？
Go 1.16+ 默认开启模块模式，但某些旧项目或 shell 环境里仍可能 fallback 到 GOPATH 模式。真正起作用的是当前目录是否含 go.mod 文件 + 当前 shell 中 GO111MODULE 的实际值。常见坑点：
-
go env -w写入的是用户级配置，若系统级/etc/profile或 shell 启动脚本里有export GO111MODULE=off，会覆盖它 - 在子 shell 或 CI 环境中，
go env显示的值未必反映真实行为，建议用go list -m验证是否进入 module 模式 - 如果项目根目录没有
go.mod，即使GO111MODULE=on，go get仍可能报working directory is not part of a module
go install 和 go run 的路径逻辑差异
这两个命令看似都“跑代码”，但查找和输出路径机制完全不同：
-
go run main.go：编译临时二进制并立即执行，不生成持久文件，也不受GOPATH或GOBIN影响 -
go install：要求当前目录在 module 根下（有go.mod），且包必须声明为可执行（package main），最终二进制输出到$GOBIN（若未设则 fallback 到$GOPATH/bin） - 注意：
go install <path></path>（如go install ./cmd/mytool）会解析相对路径，但不会自动 cd 进目标目录——路径错误时提示模糊，容易误判为环境问题
代理设置为什么总在 go env 里失效？
go env -w GOPROXY=... 看似一劳永逸，但实际生效依赖三个条件同时满足：
- Go 版本 ≥ 1.13（老版本不识别该变量）
-
GO111MODULE必须为on或auto（off下 proxy 被忽略） - 代理地址必须可连通，且返回 HTTP 200 —— 某些镜像站（如
https://goproxy.cn）已停服，但配置残留会导致go get卡住 30 秒后 fallback 到 direct，看起来像“慢”，实为重试超时
最稳妥的验证方式不是看 go env 输出，而是运行 go list -m -u all 2>&1 | head -n 3，观察是否出现 Fetching... 或直接报 proxy 连接失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
