降级模块版本必须用 go mod edit -require=module@vx.y.z 强制修改 go.mod，再执行 go mod tidy；go get 默认遵循最小版本选择（mvs），无法可靠降级，且需注意兼容性、vendor 同步与运行时契约风险。
go get 降级模块版本会静默失败
直接运行 go get example.com/lib@v1.2.0 并不能可靠降级——如果当前 go.mod 已锁定更高版本（比如 v1.5.0），且该模块被其他依赖间接引用，go get 往往只更新 go.sum 或干脆不生效，而不会修改 go.mod 中的 require 行。
这是因为 go get 默认执行“最小版本选择”（MVS），它优先满足所有依赖的约束，而非无条件覆盖。你看到的 go: downloading example.com/lib v1.2.0 日志，不代表版本真的被采纳进构建图。
- 用
go get -u=patch只升不降，完全无效于降级 - 加
-d参数跳过构建，仍无法绕过 MVS 规则 - 执行后运行
go list -m example.com/lib，若输出仍是v1.5.0，说明没成功
go mod edit -require 是唯一可控的降级方式
想明确把某个模块钉死到旧版本，必须手动编辑 go.mod 的 require 声明，而 go mod edit -require 就是为此设计的命令——它强制重写 require 行，不经过 MVS 推导。
注意：它不会自动处理兼容性问题，也不会校验该版本是否能被其他依赖接受。你得自己担起这个责任。
- 降级单个模块：
go mod edit -require=example.com/lib@v1.2.0 - 如果模块已存在 require 行，该命令会覆盖；如果不存在，会新增
- 执行后必须紧接着运行
go mod tidy，否则可能因依赖冲突导致构建失败 - 若出现
build constraints exclude all Go files类错误，大概率是降级后某子模块缺失必要构建标签或 Go 版本不匹配
降级后 go mod tidy 报 conflict 怎么办
go mod tidy 在降级后报类似 require example.com/lib: version "v1.2.0" does not satisfy all dependencies，说明其他依赖（直接或间接）要求更高版本，比如 v1.4.0+。Go 拒绝引入违反约束的版本。
这不是 bug，是模块系统在保护一致性。你有两个实际选择，而不是“重试”：
- 检查谁在拉高版本：
go mod graph | grep example.com/lib，定位具体依赖路径 - 若确定可忽略兼容风险，用
go mod edit -replace强制替换：go mod edit -replace=example.com/lib=example.com/lib@v1.2.0 - 或者升级那个“卡住”的上游依赖，让它适配你要降的版本（更稳妥但成本高）
- 切勿删
go.sum或手动改它——checksum 会失效，后续go build直接报错
go mod vendor 下降级模块的副作用
如果你项目启用了 go mod vendor，降级后记得重新运行 go mod vendor。否则 vendor/ 里还是旧版代码，而 go build -mod=vendor 会按 vendor 目录构建，和 go.mod 声明不一致。
更隐蔽的问题是：vendor 不会自动剔除已被降级模块间接引用、但新版本不再需要的子模块。它们会滞留在 vendor/ 里，造成体积膨胀甚至潜在符号冲突。
- 清理残留：
go mod vendor -v会打印哪些包被排除，配合git status vendor/看变化 - 不要用
rm -rf vendor && go mod vendor然后手动恢复某些目录——vendor 是完整快照，混入手工内容会导致不可复现行为 - CI 中建议始终用
go mod vendor生成，而非提交部分 vendor
降级不是回滚按钮。模块版本之间常有隐式契约：类型定义、HTTP API 路径、配置结构体字段……这些都不会在 go list 或 go build 里报错，直到运行时 panic 或请求 404。
