go项目依赖版本靠go.mod声明+go get@version拉取+go.sum校验保障；手动改go.mod易被覆盖，最稳方式是用go get指定版本并信任工具链自动维护。
Go 项目本地依赖版本不是靠“配置”出来的，而是靠 go.mod 显式声明 + go get @version 精确拉取 + go.sum 校验保障的。手动改 go.mod 版本号再跑 go mod tidy 是可行路径，但容易被后续命令覆盖或忽略校验；最稳的方式是只用 go get 指定版本并信任 Go 工具链自动维护。
用 go get package@version 锁定直接依赖
这是最常用、最不容易出错的方式。Go 会自动更新 go.mod 中的 require 行，并同步写入 go.sum 校验和。
- 指定语义化版本：
go get github.com/sirupsen/logrus@v1.9.3—— 推荐，稳定可重现 - 指定 commit：
go get github.com/sirupsen/logrus@8b653e7—— 适合临时验证未发版修复 - 避免用分支名：
go get github.com/sirupsen/logrus@master—— 分支内容会变，破坏构建一致性 - 降级需加
-u=patch或先删go.mod对应行再go mod tidy，否则go get默认不降级
间接依赖版本必须显式 require 才能锁定
go.sum 会记录所有传递依赖的哈希值，但它不“锁版本”——它只校验你实际下载的内容。如果某个间接依赖在不同机器上解析出不同版本（比如 github.com/pkg/errors 被两个不同主版本的库各自拉取），说明它没被显式约束。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 运行
go mod graph | grep errors查看谁引入了它 - 在
go.mod中手动加一行：require github.com/pkg/errors v0.9.1 - 再执行
go mod tidy，它会保留该版本，并确保所有机器都用这个 - 不这么做，CI 可能某天突然拉到
v0.10.0，而你代码没测过
go build -mod=vendor 不等于“本地依赖”，只是切换加载路径
生成 vendor/ 目录后，go build 默认仍走模块缓存（$GOPATH/pkg/mod）。要真正只读 vendor/，必须显式加参数。
- 正确用法：
go build -mod=vendor—— 强制只从vendor/加载包 - 漏掉
-mod=vendor，即使有vendor/目录，构建也可能用缓存里的不同版本 -
go mod vendor不复制replace的本地路径，也不包含仅用于测试的依赖（如_test中 import 的包） - CI 脚本里最容易忘这个参数，导致本地构建通过、流水线行为不一致
GOPROXY 必须禁用 fallback，否则版本号形同虚设
默认 GOPROXY=https://proxy.golang.org 在找不到你写的 @v1.9.3 时，会 fallback 到 direct 并拉最新版——这会让 go get github.com/foo/bar@v1.9.3 实际下载 v1.10.0。
- 安全设置：
GOPROXY=https://goproxy.cn,direct（国内推荐）或GOPROXY=https://proxy.golang.org,direct - 绝对不要设
GOPROXY=direct—— 失去代理缓存和校验，网络差时构建极慢且不可靠 - 私有模块加
GOPRIVATE=git.company.com/*，避免被代理拦截 - CI 环境中应硬编码这些变量，而不是依赖开发者本地配置
真正难的不是操作本身，而是理解 go.mod 是声明、go.sum 是校验、vendor/ 是加载路径——三者职责不同，混用或漏掉任一环，都会让“本地依赖版本”变成幻觉。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
