然后，在业务代码中按照官方文档实例化了 client := resty.New() 对象，紧接着我想先启动一下项目，看这个包是否正常可用，效果，执行 go run main.go 下令时，就报以下错误了。
报错了 问题分析
我们可以看到报错提示是：note: module requires Go 1.17 因为，我现在维护的这个项目是两年前写的，那个时候 Go 比较稳固的版本照旧 go 1.16 因此，这个项目也是基于 go 1.16 版本写的。可近期 Go 的版本迭代非常快，截止发稿，现在 Go 已经迭代到 go 1.22.2 版本了，而且每个版本之间差异也不小，因此跨版本之后就必要解决一些兼容性问题。
回到刚刚的报错提示：module requires Go 1.17 我们大抵可见就是有部门插件包依赖了 Go 1.17 高版本，而我现在本地版本照旧 Go 1.16，版本不兼容导致，那么，应该怎样解决这个问题呢？
探究解决方案
当然，我们可以直接升级一下 Go 的版本，这个问题应该就会迎刃而解。但是，这个项目已经在生产环境上跑了两年多了，现在贸然的去升级 Go 版本，感觉照旧有些不妥，毕竟没有什么比项目稳固更加告急了。
不能去升级 Go 版本，那就只有一种解决方案了。 找到有问题的插件包，然后对有问题的依赖包进行降级就好了。但是，问题是：怎样快速且准确的找到这个依赖包呢？
我们再回到刚刚的报错提示，可以仔细查察到，可能跟 golang.org/x/sys@v0.13.0 这个包有关系，毕竟错误信息中就含有它。
那么，按照这个思路，我们可以一步一步查到每个包的依赖，方便我们好定位问题。
一般情况下，此时，我们可能会想到直接利用 go mod graph 下令来查察项目现有的结构图，但是，如果这个项目依赖的包不算多，我们还可以勉勉强强捋得清楚相关的依赖，如果依赖包比较多了，估计也看麻了吧……
借助工具来查找依赖关系
你会发现根本无从看起，那么，我们是否可以借助某些工具来查察呢？其实，我也不确定有没有这样的工具，那照旧老套路呗，直接去 Github 上搜一波试了看，效果，一搜还真有！
就是这个包：https://github.com/PaulXu-cn/go-mod-graph-chart 看了下包先容：“一个能将 go mod graph 输出内容可视化的无依赖小工具” ，这不正是我必要的嘛！
果断用起来！
由于这个小工具是一个二进制文件，于是直接利用 go install 下令安装了下。
利用工具 然后在项目根目次下执行 go mod graph | gmchart -keep 1 （设置 -keep 1 是为了包管 HTTP 服务永不退出，当然也可以完全不设置，如果不设置的话 gmchart 启动的 HTTP 服务就只会启动一分钟。）
启动工具 当你执行完以上下令之后，会在浏览器中自动打开一个可视化的展示图表。这个工具其实就是将 go mod graph 下令输出的内容以树状的情势渲染成 web 页面展示了出来，更加方便我们查察每个包的依赖关系。
