go 1.11+ 默认启用模块模式，go get 因最小版本选择（mvs）策略可能升级间接依赖；安全更新应指定版本并验证，replace 可用于私有依赖替换，vendor 需配合 -mod=vendor 使用且需手动更新。
Go 1.11+ 默认启用 go mod，无需手动开关；项目根目录下有 go.mod 文件即进入模块模式，GO111MODULE=on 不再是必需项。
为什么 go get 会升级间接依赖？
Go 的模块解析默认采用「最小版本选择（MVS）」策略：只要某个直接依赖要求某模块 ≥v1.5.0，而你本地只有 v1.2.0，go get 就会拉取满足所有依赖的最低可行版本——这常导致看似无关的间接依赖被升级。
- 执行
go get -u会更新所有直接依赖及其子依赖到最新次版本（如 v1.x → v1.y），风险高 - 更安全的做法是：只更新指定包，例如
go get github.com/sirupsen/logrus@v1.9.3 - 检查实际变更：运行
go list -m all | grep logrus确认版本，再用go mod graph | grep logrus查它被谁引入 - 若想锁定间接依赖版本，可显式添加
require github.com/sirupsen/logrus v1.9.3 // indirect到go.mod，然后go mod tidy
如何安全替换私有仓库或 fork 的依赖？
当需要使用内部镜像、GitHub fork 或尚未发布的分支时，replace 是唯一可靠方式；go mod edit -replace 修改的是 go.mod，但必须配合 go mod tidy 才真正生效。
- 替换为本地路径：
go mod edit -replace github.com/orig/lib=../lib（路径需为绝对路径或相对于 module 根目录） - 替换为私有 Git URL：
go mod edit -replace github.com/orig/lib=git@git.example.com:team/lib.git@main - 若目标仓库无 go.mod，需先在该仓库根目录运行
go mod init github.com/orig/lib，否则go build会报no required module provides package - 注意 SSH URL 需配置
~/.gitconfig或环境变量GIT_SSH_COMMAND，否则go mod download会卡住
go mod vendor 后为什么构建仍联网？
go mod vendor 只复制 vendor/ 下的源码，并不改变模块解析逻辑；Go 编译器仍会读取 go.mod 并尝试校验 checksum，若 go.sum 缺失条目或网络不可达，就会失败。
立即学习“go语言免费学习笔记（深入）”；
- 确保执行了
go mod vendor和go mod verify均无报错 - 构建时加
-mod=vendor参数：go build -mod=vendor，否则默认走readonly模式并可能回源 - CI 中建议统一设环境变量：
export GOSUMDB=off（跳过 sumdb 校验） +go build -mod=vendor - vendor 内容不会自动更新，
go mod vendor必须在每次go.mod变更后重新运行
模块校验和（go.sum）不是“锁文件”，它记录的是每个模块版本的哈希值，而非精确依赖树；多人协作时，go.sum 冲突很常见，但只要 go mod verify 通过，就说明内容一致——别手动删行，也别盲目接受合并工具的“保留双方”结果。
