必须提交go.mod和go.sum，否则协作必然出错；发布v1.0.0前module路径须含/v1后缀，否则go get报错；跨团队需统一GOPROXY/GOPRIVATE配置，并通过PR+自动化验证升级。
go.mod 和 go.sum 必须提交，否则协作必然出错
多人跨团队协作时，go.mod 和 go.sum 不提交到 Git，等于没锁版本。CI 构建、新成员拉代码、甚至你本地重装 GOPATH 后 go build 都可能拉到不同版本的依赖——因为 Go 会 fallback 到最新兼容版或伪版本（如 v0.0.0-20240310111030-abc123），而这不是你测试过的。
-
go.sum缺失会导致go mod verify失败，CI 可能直接中断 - 即使
go.mod存在，若没提交go.sum，不同机器上go mod download可能校验失败或静默降级 - 团队中有人手动删了
go.sum再go mod tidy，就可能引入未审计的间接依赖
发布 v1.0.0 前必须改 module 路径加 /v1
Go 对 v1+ 版本有硬性路径约束：如果模块要发布 v1.0.0 标签，go.mod 中的 module 行必须包含 /v1 后缀。否则其他项目 go get github.com/user/repo@v1.0.0 会报错：invalid version: module contains a go.mod file, so major version must be compatible。
- 错误做法：保持
module github.com/user/repo不变，只打v1.0.0标签 → 其他项目无法导入 - 正确做法：先改
go.mod为module github.com/user/repo/v1，再git commit，再git tag v1.0.0，最后git push --tags - v0.x 不需要后缀，但一旦升 v1，旧路径
github.com/user/repo和新路径github.com/user/repo/v1就是两个独立模块，不能混用
GOPROXY 和 GOPRIVATE 必须统一配置
跨团队协作常涉及私有模块（如内部 SDK）和公共依赖混合使用。若各团队 GOPROXY 设置不一致，有人走代理、有人直连、有人漏配 GOPRIVATE，就会出现“你能 go get，我拉不到”的问题，尤其在 CI 环境下更隐蔽。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 推荐统一设置：
GOPROXY=https://proxy.golang.org,direct+GOPRIVATE=git.company.com,*.internal -
GOPRIVATE值必须覆盖所有私有域名，且支持通配符；漏写子域（如只写git.company.com却访问api.git.company.com）会导致 404 - CI 脚本里别依赖用户环境变量，应在 job 开头显式
go env -w GOPROXY=...和go env -w GOPRIVATE=...
多团队共用模块时，升级必须走合并 PR + 自动化验证
一个被多个团队引用的公共模块（如 github.com/org/shared）升级时，不能由某个团队直接 go get -u 提交 go.mod。这会引发版本漂移、API 不兼容、甚至破坏其他团队的构建流水线。
立即学习“go语言免费学习笔记（深入）”；
- 升级应由模块维护方发起 PR，含变更说明、兼容性标注（是否 breaking）、以及
govulncheck报告 - CI 必须跑
go list -m all检查依赖树是否引入冲突，且强制执行go mod verify - 建议在根目录加
Makefile封装：make deps-check（运行go mod tidy && go mod verify）和make deps-update MODULE=github.com/org/shared@v1.2.3
go.mod 中 replace 指令在跨团队场景下的副作用——它只在本地生效，不会被 go get 识别。如果某个团队靠 replace 临时调试，却忘了删掉再提交，其他团队 go build 会直接失败。 
