Go Modules 是否启用取决于 go.mod 文件存在与否及 GO111MODULE 环境变量值；go mod init 指定的模块名决定 import 路径和依赖解析，不可随意更改。
Go Modules 在 Go 1.11 中默认可用，但不会自动启用——必须显式初始化或通过环境变量/项目结构触发。是否启用，取决于你当前目录下有没有 go.mod 文件，以及 GO111MODULE 环境变量的值。
如何判断当前是否在 Go Modules 模式下运行
Go 不会“全局开启模块”，它按目录逐级判断：只要当前工作目录或任意上层目录存在 go.mod，且 GO111MODULE 不是 off，就进入 Modules 模式。
-
go env GO111MODULE返回on或auto（Go 1.16+ 默认为on） -
ls go.mod存在，且go list -m能输出模块路径（如example.com/myproj） - 执行
go build时出现go: downloading ...日志，说明正在拉取 module 依赖 - 如果仍从
$GOPATH/src加载包，大概率还在 GOPATH 模式（GO111MODULE=off或目录无go.mod）
初始化一个新模块：go mod init 的实际行为
go mod init 不只是创建文件，它决定整个项目的模块根路径和依赖解析起点。模块名不是随便写的，它会影响后续 import 路径和 proxy 行为。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 推荐用真实代码托管地址初始化，例如
go mod init github.com/you/repo，即使还没 push - 如果只本地开发，可以用虚拟域名如
go mod init example.org/local，避免将来重命名仓库时改 import 路径 - 不带参数运行
go mod init会尝试从目录名或父路径推断模块名（不可靠，尤其路径含空格或大写字母时） - 初始化后立即执行
go mod tidy，否则go.mod里可能缺间接依赖，go.sum也为空
GO111MODULE=off 为什么还会偷偷生效
即使设了 GO111MODULE=off，只要当前目录有 go.mod，Go 命令仍会读取它并启用 modules 功能——这是 Go 1.14+ 的强制行为，off 只禁用自动发现，不绕过已存在的 go.mod。
立即学习“go语言免费学习笔记（深入）”；
-
GO111MODULE=off仅对无go.mod的目录有效；一旦存在，模块逻辑照常运行 - 常见误操作：在旧 GOPATH 项目里手动加了
go.mod，却以为GO111MODULE=off能“关掉它”，结果构建失败或依赖错乱 - 验证方式：在有
go.mod的目录下运行go env GO111MODULE和go list -m，两者都反映真实状态 - 跨团队协作时，
.bashrc或Makefile里硬写GO111MODULE=off是隐患，应统一以go.mod为准
模块路径一旦写进 go.mod，所有 import 语句就得跟它对齐；改模块名不是改个文件那么简单，而是牵扯到 import 路径重写、CI 缓存失效、vendor 同步逻辑变化。很多人卡在第一步——不是不会敲命令，是没意识到 go mod init 的名字决定了未来半年的 import 报错频率。
