voidint
@akayj 帮忙看下
I have cleared the cache: `go clean -modcache`
README中有说明，需要打开以下两个环境变量。 ```shell export G_EXPERIMENTAL=true export G_HOME=xxx/yyy/zzz/.gvm ```
- ustc镜像站点使用的是 Nginx的[ngx_http_autoindex_module](https://nginx.org/en/docs/http/ngx_http_autoindex_module.html)模块，类似情况的镜像站点还有很多，比如[azure.cn](https://mirror.azure.cn/go/)。 - 增加 autoindex 采集器后，统一处理针对这类型的镜像站点的 go 版本信息采集，既**一个采集器可针对一类的镜像站点进行采集，而不是为每个镜像站点分别实现一个采集器**。 - `G_MIRROR`环境变量支持新扩展写法 - 完整写法：`export G_MIRROR='采集器名|镜像站点URL'`，如`export G_MIRROR='fancyindex|https://mirrors.nju.edu.cn/golang/'`。 - 简写语法：`export G_MIRROR=镜像站点URL`，如`export G_MIRROR='https://mirrors.nju.edu.cn/golang/'`。注意：**简写写法仅针对已知并完成适配的镜像站点，而完整写法则可以针对已知或匹配采集器的未知镜像站点。**
> 单独使用redis实现 `cache` 接口就好了，后续 `redis` 准备移除，建议用户自己实现。 @voidint `Cache`这个接口是有了，但库使用方也需要一个开箱即用的东西，不能说因为水泥、砂石、砖头、钢筋都有了，就让你我这样的人都去自己造房子。况且，移除 redis 实现是一个破坏性变更。
- 你指的应该是 import path 从`github.com/go-redis/redis/v8`改成了`github.com/redis/go-redis/v9`是吧？这个和移除 redis 实现没必然联系吧？假设现在用的就是最新的`github.com/redis/go-redis/v9`，那过段时间上游变成了`github.com/redis/go-redis/v10`，那和当前的现状不是一样吗？ - 假设把Redis的实现删除了，那 memcache 实现如何处理呢？上游的 memcache 库依然会有升级的可能。 - 项目依赖库版本不是最新的这种情况太正常不过了，调用方最多也就是多了一个间接依赖。如果因为这样的原因，把 redis 和 memcache 这类开箱即用的实现删除，交给调用方自己去实现，那么结局只有两个：1、大家都自己写 redis 实现，无法做到开箱即用，增加了使用成本；2、直接使用 memory 这个内置实现，在多个实例的情况下，这个实现是没法用的，使用方在不了解的情况下可能还会抱怨这是 bug。
> [@kevwan](https://github.com/kevwan) 最新版生成 types.go 文件存在问题，使用 v1.8.2 时是正常的 使用 v1.8.3 时报错 export GOCTL_EXPERIMENTAL=off
我没接触过，有没有现成的公开仓库？有时间会研究下怎么接入
- 感谢你的建议，我也是 nvm 用户，所以你的诉求我能理解。 - 但是，go 版本并不完全遵循语义化版本号，也就是从`1.21.0`版本开始才有所变化。比如用户安装了`1.18`、`1.18.1`、`1.18.10`等多个版本，此时执行`g use 1.18`，这就存在二义性。
- 引入新的环境变量或者命令行选项方式来去除二义性，这我并不赞同。引入某个机制来解决问题，前提是这个机制带来的成本得低于这个待解决问题本身，不然都得不偿失了。 - 让用户二次输入的方式也并不理想。 - 你描述的第一种方式也有可以借鉴的地方：当输入的模糊版本号（暂且这么称呼）大于等于`1.21`时，自动切换本地已安装的该版本的最新版本；否则，严格按照指定的版本号进行切换。这种方式我觉得可以考虑。