Go modules是官方强制的依赖管理机制，go.mod和go.sum必须由命令生成并提交，replace仅限当前模块生效，CI需校验tidy一致性以防止构建漂移。
Go modules 是唯一可行的现代包管理方案
Go 1.11 引入 modules 后，vendor 目录和 GO111MODULE=off 模式已不适用于协作开发。团队若仍在用 dep、glide 或手动 git submodule，会在 go build 行为、CI 一致性、CVE 修复响应上持续出问题。Modules 不是“可选优化”，而是 Go 官方锁定的依赖契约机制。
go.mod 必须提交且禁止手写
go.mod 是机器生成的声明文件，不是配置文件。团队中任何成员执行 go get、go mod tidy 或升级依赖后，都必须提交更新后的 go.mod 和 go.sum。常见错误包括：
- 忽略
go.sum提交 → CI 构建时校验失败，报错checksum mismatch - 手动编辑
go.mod中的require版本号（如改成v1.2.3）→ 下次go mod tidy会覆盖，或引发 indirect 依赖混乱 - 在
go.mod中保留注释或空行 →go mod命令会自动格式化并删除，造成无意义 diff
正确做法：所有变更通过命令驱动：
go get github.com/sirupsen/logrus@v1.9.3 go mod tidy git add go.mod go.sum
统一使用 replace 做私有模块或临时 patch
团队内部多个服务共用一个私有工具库（如 gitlab.example.com/go/utils），或需临时修复上游 bug 时，不能靠改本地 $GOPATH 或软链接。必须在根 go.mod 中声明 replace：
立即学习“go语言免费学习笔记（深入）”；
replace gitlab.example.com/go/utils => ./internal/utils replace github.com/gorilla/mux => github.com/gorilla/mux v1.8.0
注意：
-
replace只在当前 module 生效，不会传递给依赖你的下游 module - 路径替换（
=> ./xxx）必须是相对路径，且目标目录含有效go.mod - 上线前必须移除临时
replace，否则生产环境无法拉取真实版本
CI 流程中强制校验 go mod 状态
仅靠开发者自觉提交 go.mod 不可靠。CI 脚本必须包含两步校验：
- 运行
go mod tidy -v并检查退出码；若输出新增/删除行，说明本地未同步 - 执行
git status --porcelain go.mod go.sum，非空则立即失败
示例 GitHub Actions 片段：
- name: Check go.mod consistency
run: |
go mod tidy -v
if [ -n "$(git status --porcelain go.mod go.sum)" ]; then
echo "go.mod or go.sum is not up to date"
exit 1
fi这点容易被忽略：很多团队只做 go build，却放过了依赖声明漂移——它不会立刻报错，但会让不同人构建出行为不一致的二进制。
