go get -u 更新后版本没变，需确认GO111MODULE=on、GOPROXY配置正确，并用go get module@version指定版本，再执行go mod tidy；无内置go mod upgrade，推荐go list -u -m all结合手动升级与测试。
go get -u 更新后版本没变？检查模块模式和 GOPROXY
Go 1.11+ 默认启用 GO111MODULE=on，但如果你在 $GOPATH/src 下运行 go get -u，它仍可能降级为 GOPATH 模式，跳过 go.mod 约束，导致看似更新了却没改版本号。确认当前是模块模式：
go env GO111MODULE输出必须是 on。同时检查代理是否拦截了版本解析：GOPROXY 设为 https://proxy.golang.org,direct 或国内可用源（如 https://goproxy.cn），否则 go get 可能拉到缓存旧版或 fallback 到 git master 分支。
想升级到特定版本？用 go get + 版本后缀语法
直接写 go get github.com/sirupsen/logrus@v1.9.3 是最明确的方式。注意三点：
- @ 后必须是有效 tag（
vX.Y.Z）、commit hash（@a1b2c3d）或分支名（@main），不能是模糊描述如@latest（它不保证语义化） - 如果该依赖被其他包间接引入，
go get会尝试满足所有约束，可能失败并提示require github.com/xxx: version "v1.9.3" does not exist—— 此时要先查该版本是否真在对应仓库 tag 列表里 - 执行后记得运行
go mod tidy清理未引用的依赖并校验go.sum
go mod upgrade 能自动升最新兼容版吗？不能，得手动指定
Go 官方没有内置的 go mod upgrade 命令。社区工具如 go-mod-upgrade 可以扫描 go.mod 并尝试升级到每个模块的最新 minor/patch 版，但它不理解你的代码是否兼容——比如 github.com/gorilla/mux 从 v1.8.x 升到 v1.9.x 可能新增了方法签名，而你没调用就不会报错，但上线后可能触发 panic。更稳妥的做法是：
- 用
go list -u -m all查出所有可升级的直接/间接依赖 - 对关键包（如 HTTP 框架、DB 驱动）逐个
go get module@version测试 - CI 中加
go test ./...和go vet ./...，防止隐性 break
vendor 目录下依赖没更新？go mod vendor 不会自动拉新版本
go mod vendor 只是把 go.mod 当前锁定的版本复制进 vendor/，不会主动升级。如果你改了 go.mod 里的版本（比如手工编辑或通过 go get），必须再跑一次 go mod vendor 才会同步。另外注意：
- 如果项目用了
-mod=vendor构建，那go build完全忽略go.sum和远程模块，只读vendor/—— 这意味着即使你go get了新版，不重 vendor 就无效 - 某些 CI 环境默认开启
GOFLAGS="-mod=vendor"，容易让人误以为依赖已更新
真正要验证 vendor 是否生效，可以删掉 vendor/ 重新生成，再 grep 某个包的 go.mod 文件看版本号。
立即学习“go语言免费学习笔记（深入）”；
版本控制真正的难点不在命令怎么敲，而在判断「这个包能不能升」「升完要不要改调用代码」「测试能不能覆盖边界路径」——go list -m -versions 和 git log 看 CHANGELOG 比任何自动化工具都管用。