当前项目已启用 Go Modules 当且仅当 GO111MODULE=on 或 auto 且项目不在 GOPATH/src 下并存在 go.mod 文件；需通过 go env GO111MODULE 和检查 go.mod 判断，避免误判。
如何判断当前项目是否已启用 Go Modules
Go 1.11+ 默认在 GOPATH 外自动启用模块模式，但项目根目录下没有 go.mod 文件就代表未初始化模块。运行 go env GO111MODULE 查看值：若为 off，则无论在哪都会禁用模块；on 强制启用；auto（默认）表示仅当不在 GOPATH/src 下且存在 go.mod 时才启用。
常见误判点：
- 项目在
$GOPATH/src下却期望用模块 —— 即使有go.mod，auto模式下也不会生效 - 执行
go build成功，但没生成go.mod—— 很可能仍处于 GOPATH 模式，依赖被隐式拉到$GOPATH/pkg/mod之外，造成协作混乱
初始化模块并设置正确 module path
在项目根目录执行 go mod init example.com/myapp，其中 example.com/myapp 是模块路径（module path），它不是 URL，而是命名空间标识，应尽量与代码公开地址一致（如 GitHub 仓库地址），便于他人 go get 引入。
关键细节：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- module path 不能以
golang.org、github.com等平台名开头却指向私有仓库，否则go get会尝试从公网拉取 - 若项目尚未托管，可用占位域名（如
mycorp/internal/app），后续迁移时需同步更新所有 import 路径 - 初始化后立即运行
go mod tidy，补全直接依赖并写入go.sum
添加/升级依赖时为什么 go get 行为和预期不符
go get 在模块模式下本质是“更新 go.mod 并下载指定版本”，不是传统意义上的“安装包”。它的行为高度依赖参数和当前上下文：
-
go get github.com/gin-gonic/gin→ 添加最新 tagged 版本（如v1.9.1），或 latest commit（无 tag 时） -
go get github.com/gin-gonic/gin@v1.8.0→ 锁定该版本，同时降级其他间接依赖以满足兼容性 -
go get -u→ 升级所有直接依赖到最新 minor/patch（不跨 major），-u=patch更安全 - 若提示
require github.com/some/lib: version "v2.0.0" invalid—— 是因为 v2+ 库必须带 /v2 后缀，module path 应为github.com/some/lib/v2
go.sum 和 vendor 目录到底要不要提交
go.sum 记录每个依赖的校验和，用于防范依赖篡改，必须提交到 Git。它不是锁文件（不像 package-lock.json），但配合 go mod download -v 可复现构建环境。
关于 vendor：
-
go mod vendor会把所有依赖复制进本地vendor/目录；go build -mod=vendor强制只读该目录 - CI/CD 中可选，但多数云构建环境（GitHub Actions、GitLab CI）已支持纯净模块缓存，无需
vendor - 若团队有离线构建需求或依赖私有 registry 不稳定，才建议
git add vendor，否则增加仓库体积且易 stale
真正容易被忽略的是：go.mod 中的 // indirect 标记 —— 它表示该依赖未被当前模块直接 import，只是其他依赖的依赖。删掉一个间接依赖的 import 后，它不会自动消失，需手动 go mod tidy 清理。
