报错“note: module requires Go 1.xx”时，应降级依赖而非升级Go。先用go mod graph和go mod why定位高版本依赖源头，再用go get指定兼容旧版本并go mod tidy自动降级间接依赖；replace仅作临时方案，上线前须移除。
报错“note: module requires Go 1.xx”时，别急着升级Go
这个提示不是编译错误，而是go build或go run在模块加载阶段的明确拒绝：当前Go版本低于模块声明的最低要求。它通常出现在引入较新生态包（如resty、hertz、golang.org/x/net等）后，且该包的go.mod中写了go 1.17或更高版本。
直接升级Go看似最省事，但生产项目往往卡在兼容性验证、CI/CD工具链、Docker基础镜像、团队环境一致性等现实约束上。真正可行的路径是——让依赖适配你当前的Go版本，而不是反过来。
用go mod graph快速定位“谁在拉高版本依赖”
错误信息里常带一个可疑模块名，比如golang.org/x/sys@v0.13.0，但它只是“症状”，不是“病根”。真正要找的是：哪个上游包强制要求了这个高版本？
- 先运行
go mod graph | grep 'golang.org/x/sys'，看输出里哪一行带@v0.13.0，并记下左边那个包名（比如github.com/spf13/cobra） - 再查它为什么需要这个版本：
go mod why -m golang.org/x/sys，会显示完整调用链，例如：-> github.com/spf13/cobra v1.8.0 -> golang.org/x/sys v0.13.0 - 如果调用链里出现
// indirect，说明它是被某个依赖悄悄带进来的，没显式require，go.mod里找不到它——这正是问题隐蔽之处
降级依赖：用go get指定兼容旧版，而非删go.sum
找到源头包后，目标不是删掉它，而是把它降到你Go版本能跑的最后一个兼容版本。比如cobra在Go 1.16下稳定可用的最后版本是v1.7.0，那就锁定它：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 执行
go get github.com/spf13/cobra@v1.7.0—— 注意不加-u，避免MVS算法又选回高版本 - 运行
go mod tidy，它会自动降级所有被cobra间接拉入的高版本子依赖（如golang.org/x/sys会退到v0.12.0） - 别手动删
go.sum，否则下次go mod tidy可能重新拉高版本；校验和必须和go.mod里写的版本严格对应 - 验证是否生效：
go list -m golang.org/x/sys应输出v0.12.0，不是v0.13.0
replace是临时止血，不是长期解药
如果某依赖实在找不到兼容旧Go的发布版本（比如作者只维护main分支），才考虑replace：
- 在
go.mod里加：replace github.com/broken/pkg => github.com/fork/pkg v1.2.0-fix - 必须同步
go get github.com/fork/pkg@v1.2.0-fix，否则replace不会触发下载 -
replace不解决根本问题：它绕过MVS，但下游模块若仍import原路径，而fork里没做兼容适配，运行时照样panic - 上线前务必删掉
replace行——CI环境若没配GOPROXY，它可能根本拉不到fork地址
真正容易被忽略的点是：很多“requires Go 1.xx”报错，源头不在你直接go get的包，而在它的二级、三级依赖里。不顺着go mod why挖到底，只盯着错误里写的那个模块改，大概率白忙活。
