Go 1.16+ 默认启用模块模式，go install 不依赖 GOPATH，需显式指定 module/path@version 或在模块根目录执行；GOPATH 多数情况下无需手动配置，仅影响 go install 输出路径和旧工具链；go build 要求在含 go.mod 的目录运行，否则报“cannot find module”。
Go 语言环境搭建本身不复杂，但实际操作中卡在 GOPATH、GOBIN、模块模式与 go install 行为差异上的人远比想象中多——尤其当你刚从 Python 或 Node.js 转过来时。
为什么 go install 不把二进制文件放到 $GOPATH/bin 里？
Go 1.16+ 默认启用模块模式（module-aware mode），go install 的行为已变更：它不再依赖 GOPATH，而是要求目标包路径以 module/path@version 形式显式指定，且默认安装到 $GOBIN（若未设置则 fallback 到 $GOPATH/bin）。
- 如果你没设
GOBIN，又没在模块根目录下执行go install，很可能什么都没装进去，终端也无报错 -
go install .只在当前模块根目录有效；go install ./cmd/xxx才能定位子命令 - 用
go install github.com/urfave/cli/v2@latest这类远程路径方式，才真正绕过本地模块上下文限制
GOPATH 还需要手动配置吗？
大多数情况下不需要。Go 安装后会自动创建 $HOME/go 作为默认 GOPATH，且仅在非模块模式（如 GO111MODULE=off）下才生效。现在几乎没人需要改它。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 检查是否被意外覆盖：
go env GOPATH—— 如果输出不是$HOME/go，再查 shell 初始化文件里有没有硬编码的export GOPATH=... - 刻意清空
GOPATH不会导致错误，只要模块路径正确、go.mod存在，构建照常进行 - 唯一仍需关注
GOPATH的场景：使用老版本工具链（如dep）、或某些 CI 脚本显式依赖它
为什么 go run main.go 成功，但 go build 出来的二进制却报 “cannot find module”？
这不是环境问题，是工作目录错了。go build 要求当前路径在模块根目录（即含 go.mod 的目录），否则它会尝试在 GOPATH 下找包，而模块路径早已脱离该结构。
立即学习“go语言免费学习笔记（深入）”；
-
go run允许在任意子目录执行，因为它只解析单个文件依赖并临时构建 -
go build和go install都严格按模块边界工作——运行前先cd到go.mod所在目录 - 常见误操作：在
project/cmd/app下执行go build -o app，结果生成的二进制仍试图从$GOPATH加载依赖
真正容易被忽略的，是 GO111MODULE 环境变量的隐式状态：它默认为 auto，只在当前目录或父目录存在 go.mod 时才开启模块模式——这意味着新建项目时，第一行 go mod init example.com/foo 必须在空目录执行，否则可能继承上级残留的模块配置。
