go项目默认用go mod管理依赖，需≥1.11版本并开启GO111MODULE；通过检查go.mod文件判断是否启用模块，初始化用go mod init；依赖管理推荐go get（显式添加）与go mod tidy（自动同步），避免混用导致checksum mismatch；校验失败时可清缓存或换代理源；go.mod和go.sum须提交git并CI校验。
Go 项目现在默认使用 go mod 管理依赖，无需额外工具或配置 GOPATH（除非兼容旧项目）。只要 Go 版本 ≥ 1.11，且 GO111MODULE 开启，就能正常初始化和拉取依赖。
如何判断当前项目是否已启用 Go Modules
检查项目根目录下是否存在 go.mod 文件。若不存在，运行 go mod init 初始化 —— 模块名通常为 Git 仓库地址（如 github.com/yourname/project），但不是必须与远程一致，只要不冲突即可。
常见误操作：
- 在已有
vendor目录的项目中直接go mod init，可能遗漏部分依赖；建议先删掉vendor再执行 - 模块名写成本地路径（如
./myapp），会导致后续go get失败或版本解析异常 - 未设置
GO111MODULE=on（尤其在 GOPATH 下），go mod命令可能静默降级为 GOPATH 模式
添加/更新依赖时该用 go get 还是 go mod tidy
go get 是显式获取并记录依赖，go mod tidy 是自动同步 go.mod 和实际 import 的依赖项。两者用途不同，不能互换。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 想引入新包：用
go get github.com/sirupsen/logrus@v1.9.3（带版本更安全） - 想清理未使用的依赖：运行
go mod tidy，它会删掉go.mod中冗余条目，并补全间接依赖（require中的// indirect注释说明） - 升级所有依赖到最新兼容版：用
go get -u；仅升级次要/补丁版本：用go get -u=patch - 避免混用
go get和手动编辑go.mod，容易导致 checksum 不匹配（go: downloading ... verifying ...: checksum mismatch）
为什么 go build 时提示 missing go.sum entry 或 checksum mismatch
这是 go.sum 校验失败的典型表现，本质是下载的模块内容与历史记录不一致，常见于：
- 模块作者强制重写了 tag（如
v1.2.0对应的 commit 被 reset 并 force push） - 本地缓存损坏（
$GOPATH/pkg/mod/cache或$GOCACHE异常） - 代理源（如 GOproxy）返回了被篡改或不一致的内容
解决方法：
- 临时绕过校验（仅调试）：
go env -w GOSUMDB=off（不推荐长期使用） - 清除本地模块缓存：
go clean -modcache，再重新go mod download - 换代理源验证：
go env -w GOPROXY=https://proxy.golang.org,direct，或国内可试https://goproxy.cn - 确认
go.sum是否被误提交了不完整行（比如只有一半 hash）—— 可删掉后运行go mod tidy重建
真正麻烦的不是初始化或拉包，而是团队协作中 go.mod 和 go.sum 的微小不一致会引发构建差异。建议把这两个文件都纳入 Git，并在 CI 中加一步 go mod verify 校验完整性。