Go 环境版本管理用哪个- -有点疑惑

基本上可以做到向上兼容, 用啥版本管理啊.

开发环境。。。我还是想保持统一的- -
@justseemore

我用 goup

goup 环境变量指到~/.go/current 就行

试试 https://github.com/voidint/g

我还在用 gvm ，感觉还行吧

asdf 无脑什么语言都一把唆~

asdf +1 虽然我是前端开发。

mise

go 不是默认就支持不同版本了吗？

mise

还有个叫 vmr ，但是 vscode 自带版本管理了不需要了吧
https://github.com/gvcgo/version-manager/blob/main/docs/readmeCN.md

在用 vfox

在用 asdf ，配置起来还是有点麻烦的。感觉可以直接使用 GoLand 中自带的 go sdk 就够用了

现在 golang 高版本的 gomod 里可以申明 toolchain 版本。

当然，我现在参与的项目的版本还不支持这个功能。升级是不可能升级的，这辈子都不可能升级的。

vfox

go download 以后有一个别名可执行文件
我没切换过

g

go 不用版本管理吧
不是兼容的吗，无脑用最新的就行了

话说不是跟生产环境搞成一样的不就完事了吗？理论上不会有问题吧。

vfox +1
用一个版本管理器管理所有语言挺方便的。

mise 秒了，所有都用这个

mise

@gongym 兼容说是兼容，可这不是理想情况吗。

按照 Hyrum’s Law ，实际上你已经依赖了 Go 内部的非公开实现，而你永远不知道你的同事和你依赖的库有什么骚操作。这样的例子其实有很多：
1. 依赖反射和 unsafe ，这些库不保证行为兼容。unsafe 就不说了。reflect 更隐蔽，比如`reflect.DeepEqual` 的行为变过。你用高版本的 Go 去编译老版本不带修复的 K8s ，你会发现一堆 CR 提交不上去。
2. 依赖黑魔法注解，一堆库被 rcs 在 Go 源码里拉耻辱柱群，这些库多半你用过：containerd 、protobuf 、sonic ；有一些改了退群了，有一些一直还在。
3. 你依赖了 golang.org/x 下面的库，这玩意的版本很玄学，兼容性就更别说了。

mise

之前好几个语言版本的管理器，全换 mise 了，好用

mise, 因为还可以管理 node, python, uv 等.

@Reficul 还以为你拿 cgo 举例，如果是这玩意的话的确一辈子都没有升级的希望了
但是你说的这些只是验证时间长度和方案选取的区别，另外升的越晚技术债积的越多

@rarpainting

是咯，越老越复杂的严肃项目，就越不敢动。。。

go 向下兼容的，开发业务不需要版本管理，直接安最新版

gvm 问题不大

GoTV: https://go101.org/apps-and-libs/gotv.html

@lysShub 并不