Go Modules 是 Go 1.11 起的官方依赖管理机制，go get 在 1.16+ 默认启用；需检查 go.mod 文件、GO111MODULE 环境变量，并避免混用 GOPATH，否则导致依赖混乱、版本不可控。
Go Modules 是 Go 1.11 起引入的官方依赖管理机制，go get 在 Go 1.16+ 默认以 Module 模式运行；直接用 go get 拉包却没初始化 Module，或混用 GOPATH 和 Module，是绝大多数依赖混乱的根源。
如何判断当前项目是否启用 Go Modules
检查项目根目录下是否存在 go.mod 文件。没有该文件，且环境变量 GOPATH 未显式设置为非默认路径，go get 会退化为旧式 GOPATH 模式（包被下载到 $GOPATH/src/），导致本地无法复现构建、版本不可控。
- 运行
go env GO111MODULE：输出on表示强制启用 Module；auto（默认）表示有go.mod就启用，否则回退；off则完全禁用 Module - 在项目根目录执行
go mod init example.com/myapp可主动初始化 Module（模块路径建议与未来发布地址一致） - 若已有
go.mod但go list -m all报错或不显示依赖，说明 Module 未正确加载，需确认是否在正确目录下操作
go get 在 Module 模式下的行为变化
go get 不再只是“下载源码”，而是“解析依赖图 + 下载指定版本 + 更新 go.mod 和 go.sum”。它默认拉取最新 tagged 版本（如 v1.2.3），而非 master 分支最新 commit。
- 添加新依赖：
go get github.com/gin-gonic/gin→ 自动写入go.mod并记录精确版本 - 升级到特定版本：
go get github.com/sirupsen/logrus@v1.9.3→ 强制锁定该版本 - 降级或撤回：
go get github.com/sirupsen/logrus@v1.8.0→ 直接覆盖原记录 - 注意：
go get -u会升级直接依赖及其所有间接依赖到最新 minor/patch 版本，极易引发兼容性问题，生产环境应避免无条件使用
go.sum 文件的作用与常见误操作
go.sum 记录每个依赖模块的校验和（checksum），用于验证下载内容是否被篡改或损坏。它不是可选配置，而是 Go 构建时强制校验的依据。
|Git删除了文件，但还会在Git 仓库历史中遗留。 - 想要从 Git 历史移除敏感信息（密码、密钥、token、私钥） - 想要删除意外提交的大文件 - 想要重写 Git 历史、移除特定文件的所有痕迹 - 提到 "force push"、"重写 commit 历史" - 需要从所有分支、所有 tag 中删除某个文件
立即学习“go语言免费学习笔记（深入）”；
- 删除
go.sum后首次go build会自动重建，但重建结果依赖当前网络拉取的包内容——若此时上游已删 tag 或换包，校验和会不同，导致构建失败 - 提交代码时必须包含
go.sum，否则协作者go build可能因校验失败中断 - 遇到
checksum mismatch错误，不要手动编辑go.sum：先确认是否误改了依赖版本或网络中间件污染了下载（如公司代理缓存旧包），再运行go clean -modcache清理模块缓存后重试
vendor 目录是否还需要？
绝大多数场景下不需要 go mod vendor。Go Modules 原生支持离线构建（模块缓存在 $GOMODCACHE），vendor 只在极少数受限环境（如 CI 禁止外网、Air-Gapped 网络）才有意义。
- 启用 vendor 后，
go build默认只读vendor/，忽略远程模块；但需额外维护vendor与go.mod同步，容易遗漏更新 - 若必须使用，每次变更依赖后务必执行
go mod vendor，并检查vendor/modules.txt是否与go.mod一致 - CI 中更推荐用
go mod download预热缓存，而非复制整个vendor目录上传，减少体积和同步开销
真正棘手的从来不是“怎么启用 Module”，而是团队成员本地 GO111MODULE 设置不一致、历史脚本残留 export GOPATH=...、或误把 go get 当成包管理器去“安装工具”（如 go get golang.org/x/tools/cmd/gopls 应改用 go install）。这些细节不统一，Module 就形同虚设。
