go modules是当前唯一推荐的依赖管理方式，自go 1.11引入、1.16起默认启用，通过go.mod精确声明版本，go.sum校验完整性，replace/exclude用于调试与规避，vendor需配合-mod=vendor才真正离线。
Go 项目中管理不同版本的依赖包，核心不是“同时用多个版本”，而是通过 go.mod 精确声明每个依赖的版本，并由 Go 工具链自动解析依赖图、解决冲突。Go Modules 不支持像 Java 或 Python 那样为同一包显式引入 v1 和 v2 两个版本——它靠模块路径区分（如 github.com/user/lib 和 github.com/user/lib/v2），否则会报错 invalid version: module contains a go.mod file, so major version must be compatible。
go get 指定版本后为什么没生效？
常见现象：执行 go get github.com/sirupsen/logrus@v1.9.3 后，go.mod 里仍是 v2.0.0+incompatible 或没变化。
- 根本原因：
go get默认行为是“升级到满足约束的最新兼容版本”，不是“精确覆盖”。如果已有更高主版本（比如 v2），它不会主动降级；如果指定的 tag 在 proxy 上不可达，它会 fallback 到 latest 并只 warn - 确认 tag 是否真实存在：
curl -I https://proxy.golang.org/github.com/sirupsen/logrus/@v/v1.9.3.info - 强制锁定写法（推荐）：
go mod edit -require=github.com/sirupsen/logrus@v1.9.3+go mod tidy - 用 commit hash 更可靠：
go get github.com/sirupsen/logrus@55046e2（绕过 tag 可用性校验）
如何让间接依赖不被意外升级？
间接依赖（你没直接 import，但某依赖用到了）常在 go get -u 时悄悄更新，导致构建结果漂移。
-
go get -u=patch只升 patch 版本，不碰 minor/major（适合日常维护） - 想完全冻结某个间接依赖？手动加
require行到go.mod中（即使没 import 它），再go mod tidy - 检查哪些间接依赖被改了：
go list -m all | grep -v 'your-module-name' - CI 中建议加检查：
git status --porcelain go.sum，非空则失败（防哈希被篡改或源变更）
vendor 目录到底要不要提交？怎么用才真正离线？
vendor 是可选的离线兜底手段，但默认不生效，且容易误以为“有了 vendor 就安全了”。
-
go mod vendor只复制go.mod里声明的依赖，不会自动更新已存在的 vendor 内容 - 构建时必须显式加
-mod=vendor：go build -mod=vendor，否则 Go 仍走 GOPROXY - vendor 必须和
go.mod/go.sum一起提交，且每次go mod tidy后要重跑go mod vendor - 私有模块或无签名仓库下，
go.sum是唯一可信依据；丢掉它，vendor 目录就失去防篡改意义
最易被忽略的一点：模块路径（module 行）一旦写进 go.mod，就决定了所有 import 语句的前缀。改路径不是简单替换字符串，而要同步改代码里的 import、CI 脚本里的路径引用，甚至 Git 仓库地址——否则 go mod tidy 会反复报错找不到包。
