Go包管理核心在于统一行为约束：go.mod和go.sum必须提交，变更须经go get/tidy/edit；私有模块需配置GOPRIVATE；vendor是否提交取决于CI构建方式，且必须校验一致性。
Go 包管理直接影响团队能否拉下代码就跑通、上线前是否突然发现依赖冲突、新人入职三小时还在查 go mod download 失败原因——核心问题不在“会不会用”，而在“是否统一约束了行为”。
go.mod 文件必须提交到 Git，且禁止手动编辑
go.mod 是 Go 模块的唯一事实来源，但它的内容不是靠手写维护的。团队里有人直接改 require github.com/some/lib v1.2.0、有人用 go get -u 升级、还有人本地 replace 临时绕过问题，结果就是：同一份代码，A 的 go build 成功，B 的 go test 报 undefined: somefunc。
- 所有变更必须通过
go get、go mod tidy或go mod edit触发，再提交生成的go.mod和go.sum -
go.sum必须提交，它不是缓存，而是校验锁——缺少它，CI 可能因镜像源差异拉到被篡改的包 - 禁止在
go.mod里写死本地路径replace example.com/foo => ../foo，这类替换应只出现在开发阶段的go.work中（Go 1.18+），且不进主干分支
私有模块无法拉取？问题大概率出在 GOPRIVATE 配置上
团队用 GitLab 自建仓库放内部 SDK，但 go get 总卡在 verifying github.com/xxx@v0.1.0: checksum mismatch 或直接 401 ——这不是网络或权限问题，是 Go 默认把所有非 golang.org/github.com 域名当公开模块走 proxy，绕过了公司内网认证。
- 在 CI 环境和每位开发者机器上，必须设置：
go env -w GOPRIVATE=gitlab.example.com/myorg/*,internal.example.com/*
- 这个环境变量要进团队文档，最好写进项目根目录的
.envrc（用 direnv）或Makefile的setup目标里 - 注意通配符语法：必须用
/*，写成gitlab.example.com/myorg不生效；多个域名用逗号分隔，不能有空格
vendor 目录要不要提交？取决于你的发布流程
有些团队坚持 go mod vendor 并提交整个 vendor/ 目录，认为“离线可构建”更稳；另一些团队觉得冗余、Git 体积大、diff 难读。其实关键不在“要不要”，而在“谁负责更新”和“何时验证”。
- 如果 CI 构建阶段明确使用
go build -mod=vendor，那vendor/就是构建必需品，必须提交，并且每次依赖变更后，由make vendor（封装了go mod vendor && git add vendor）统一更新 - 如果 CI 用的是
go build（默认走 module mode），那vendor/就是纯本地优化，不提交也行，但必须在.gitignore明确写入/vendor，避免误提 - 无论哪种，都要在 CI 加一步：
go mod verify
，确保go.sum与当前依赖树一致，防人为删改
最常被忽略的一点：Go 的模块机制本身不解决“多版本共存”问题。一个服务引用了 libA v1.3，另一个服务组件又强依赖 libA v2.0，这时不是 go mod 能自动隔离的——得靠团队约定模块边界，或拆成独立二进制，而不是指望 replace 在主模块里打补丁撑过上线。
