go modules 是标准依赖管理方式，需掌握 replace（本地调试）、exclude（排除问题版本）、-mod=vendor（确保离线构建）及间接依赖升级策略以保障构建稳定性和协作效率。
Go Modules 从 Go 1.11 引入，1.16 起默认启用，现在已是标准依赖管理方式。但很多项目仍只用 go mod init 和 go build，错过真正提升协作效率和构建稳定性的关键能力。
如何用 replace 在本地调试未发布的模块
当你依赖的某个 github.com/user/lib 还在开发中、尚未打 tag，又不想反复 go mod edit -replace 手动改 go.mod，可以用 replace 直接映射到本地路径：
replace github.com/user/lib => ./local-lib
注意：该路径必须包含有效的 go.mod（哪怕只是空的 module github.com/user/lib），否则 go build 会报 no matching versions；替换仅对当前 module 生效，子 module 不继承；CI 环境需确保该路径不存在或被显式取消（可用 go mod edit -dropreplace 或临时注释）。
何时该用 exclude 而不是 replace 或 require
exclude 不是“忽略依赖”，而是**强制排除某个版本范围**，典型场景是规避已知 panic 的中间版本：
立即学习“go语言免费学习笔记（深入）”；
- 某依赖 v1.2.3 有内存泄漏 bug，v1.2.4 已修复，但 v1.2.5 又引入新 crash —— 此时
exclude github.com/x/y v1.2.5比replace更干净 - 你无法修改上游
go.mod，但下游构建必须跳过某个不兼容的间接依赖（如golang.org/x/net的旧版与 Go 1.22 冲突） -
exclude不影响go list -m all输出，但go build绝对不会选中被 exclude 的版本
为什么 go mod vendor 后还要加 -mod=vendor
go mod vendor 只是把依赖复制进 vendor/ 目录，Go 编译器默认仍走 module mode（查 $GOPATH/pkg/mod）。不加 -mod=vendor，go build 会忽略 vendor/，导致：
- CI 构建失败（网络不可达时无法 fetch module）
- 本地
go.sum和vendor/内容不一致，引发校验失败 -
vendor/成为摆设，失去离线构建和版本锁定意义
推荐写成 go build -mod=vendor -o myapp ./cmd/myapp，CI 脚本里也应显式声明，避免依赖环境变量或隐式行为。
如何安全地升级间接依赖（// indirect）
间接依赖不会出现在 go.mod 的 require 块顶层，但它们实际参与构建。直接 go get foo@latest 可能意外升级一堆间接依赖，引发兼容问题。稳妥做法是：
- 先用
go list -m -u all | grep 'indirect$'查出所有间接依赖及其可升级版本 - 逐个确认变更日志，再执行
go get example.com/bar@v1.5.0（而非@latest） - 升级后运行
go mod graph | grep bar验证是否仍为间接引入，以及由谁引入 - 若某间接依赖被多个路径引入且版本不一致，
go mod tidy会自动选择最高兼容版本，但可能不是你预期的——此时需用require显式固定
间接依赖的版本漂移是最难排查的构建不一致来源，尤其在团队共用基础库时，一个成员 go mod tidy 就可能悄悄改变整个项目的依赖图。
