go mod tidy 会自动升级依赖？不是你想的那样
它只按 go.mod 里声明的版本约束拉取满足条件的最新兼容版，不会无脑升到 v2+ 或 major 不兼容分支——除非你写了 ^1.2.0 这类宽松约束，或根本没锁版本。
常见错误现象：go mod tidy 后发现 github.com/sirupsen/logrus 从 v1.9.3 跳到了 v2.0.0，程序直接编译失败。原因：你本地 go.mod 里写的是 github.com/sirupsen/logrus v0.0.0-00010101000000-000000000000（即未显式指定），而模块索引返回了 v2 的伪版本（带 +incompatible 标记）。
- 用
go get github.com/sirupsen/logrus@v1.9.3显式指定版本，再跑go mod tidy - 避免用
go get -u，它默认升级所有间接依赖，极易破坏兼容性 - 检查
go.mod中该包行末是否带// indirect，如果是，说明你没直接 import，但被其他包带进来了——这时要定位源头包去约束
降级依赖时 go get @vX.Y.Z 不生效？先清缓存再试
Go 模块下载后存在本地缓存（$GOPATH/pkg/mod/cache/download/），go get 默认复用已缓存的 zip 和 .info 文件，即使你指定了旧版本，也可能因缓存元数据“认为”无需更新。
使用场景：线上环境出 bug，确认是 golang.org/x/net v0.17.0 引入的 regression，需回退到 v0.16.0。
立即学习“go语言免费学习笔记（深入）”；
- 执行
go clean -modcache彻底清空模块缓存（开发机可接受；CI 环境建议改用GO111MODULE=on GOPROXY=direct go mod download避免污染） - 再运行
go get golang.org/x/net@v0.16.0，注意别漏掉@符号 - 检查
go.mod是否出现两行同名模块（如同时存在v0.16.0和v0.17.0），若有，手动删掉旧行并go mod tidy
想锁死某个依赖不被任何操作影响？用 replace + require 拦截
当上游包发布了一个破坏性更新（比如把 func Do() error 改成 func Do(ctx context.Context) error），而你又暂时无法修改业务代码，就得强制锁定旧版——replace 是唯一可靠手段。
性能影响：无；兼容性影响：仅限本项目，不影响其他模块引用该依赖时的行为。
- 在
go.mod末尾加一行：replace github.com/hashicorp/go-version => github.com/hashicorp/go-version v1.4.0 - 必须配合
require github.com/hashicorp/go-version v1.4.0（即使你没直接 import，也要显式 require，否则go mod tidy可能删掉 replace） - replace 目标路径必须完整，不能省略域名（如写成
go-version => ...会报错invalid module path）
Go 版本和依赖版本不是一回事，别混淆 go version 和 go.mod 的 go 行
go version 输出的是当前 CLI 工具链版本，而 go.mod 顶部的 go 1.21 行只控制语言特性和内置函数行为（如泛型、any 别名等），它**不决定依赖能用什么版本**。
容易踩的坑：把项目 go 行从 1.19 升到 1.21 后，以为能自动用上 net/http 新增的 Request.WithContext，结果编译报错——因为该方法实际来自 golang.org/x/net/http，和 Go 工具链版本无关，得单独 go get 对应模块。
- 查依赖真实支持的 Go 版本，看其
go.mod文件里的go行，不是你的项目 - 升级 Go 工具链后，务必跑一遍
go test ./...，有些依赖在新 Go 版本下会触发更严格的 vet 检查（比如 nil map 写入） - CI 中固定
GOPATH和GOCACHE路径，否则不同 Go 版本间缓存混用可能导致go build行为不一致
最麻烦的其实是间接依赖：你没动一行代码，只是另一个团队升级了他们 SDK 的依赖，结果你的服务上线就 panic。这时候光看 go.mod 没用，得用 go list -m -u all 和 go mod graph | grep 一层层挖。
