go get @vX.Y.Z 未更新 go.mod 是因 MVS 算法校验依赖图后拒绝不兼容版本，需确认路径一致性、tag 可用性及缓存状态；手动修改 require 后必须执行 go mod tidy 同步 go.sum，replace 仅重定向路径而非回滚版本，最稳回滚方式是 git checkout + go mod download。
go get @vX.Y.Z 为什么没更新 go.mod
不是命令失效，而是 MVS（最小版本选择）算法在起作用：Go 不会无条件写入你指定的版本，而是检查整个依赖图是否允许它被选中。常见原因包括：
- 其他依赖已 require 同一模块的更高主版本路径（如
github.com/foo/bar/v2），而你试图回滚的是v1路径——它们被视为完全不同的模块 - 目标版本 tag 在当前
GOPROXY上不可见（已被作者删除、未发布、或私有仓库未配置GOPRIVATE） - 本地缓存里已有更高版本，且该版本满足所有约束，MVS 就不会降级
验证方式：运行 go list -m all | grep foo/bar，看实际生效的是哪个路径+版本；再用 curl -I https://proxy.golang.org/github.com/foo/bar/@v/v1.2.3.info 确认 tag 是否可访问。
手动改 go.mod 后必须立刻 tidy
直接编辑 require github.com/foo/bar v1.2.3 行能“写进去”，但不等于生效。Go 不会自动校验、下载或更新 go.sum —— 这会导致后续 go build 失败，报 missing go.sum entry 或 invalid version。
- 改完必须立即执行
go mod tidy：它会重新解析所有 import、补全缺失依赖、移除未用项，并同步更新go.sum - 如果
tidy报错说 “no matching versions”，说明该版本不存在或不可拉取，得换 tag 或 commit hash - 切勿跳过
go mod download：尤其在 CI 或离线环境，go build不保证触发下载，缺包就直接失败
replace 不是回滚，是绕过
replace 不改变模块版本选择逻辑，只重写 import 解析路径。它常被误当作“回滚方案”，但本质是临时遮蔽——容易掩盖真实冲突，且上线风险高。
立即学习“go语言免费学习笔记（深入）”；
- 仅适用于：本地调试 patch、对接 fork 分支、迁移私有镜像
- 若 replace 目标是同一模块不同版本（如
github.com/foo/bar => github.com/foo/bar v1.2.3），它不会生效：Go 仍按原路径解析，replace只对路径变更有效 - 验证是否真生效：
go list -m all输出中应出现=>符号指向你指定的目标 - 上线前必须删掉
replace并跑通go mod tidy；否则 CI 环境可能因GOPROXY差异 panic
最稳的回滚其实是 git checkout
只要每次 go mod tidy 后都提交 go.mod 和 go.sum，Git 就是最可靠的版本快照工具。比任何命令都更确定、可重现。
- 操作三步：
git checkout abc1234 -- go.mod go.sum→go mod download→go build -
go mod download不可省：它确保本地$GOPATH/pkg/mod缓存里有对应版本，避免构建时静默失败 - 别依赖
go build自动拉取——某些GOPROXY=direct或离线配置下，它会跳过下载并报错
真正复杂的地方不在命令怎么敲，而在搞清“谁在拉这个模块”和“它为什么必须是这个版本”。go mod graph 和 go mod why 比盯着 go.mod 手动猜快得多。
