go的编译环境的系统的版本和使用编译产物的系统的版本必须一致吗?

[kohlersDagger]

Golang (或者说编译性的开发语言)用的比较少,大部分时间是 Java,少许 rust 经验,以下问题请教一下:

---

背景:
我的系统是 MacOS 10.14,通过终端执行如下命令

$ ./xray --version
Xray 24.11.5 (Xray, Penetrates Everything.) afc7ec5 (go1.23.2 darwin/amd64)

可以看出,该 xray binary 是 go1.23.2编译而来的,而根据go1.20 是最后一个支持 Macos 10.14 的版本,在我的理解里,该 binary 的可用性必定是不完整,即可能部分功能还可以使用,可能完全无法使用,也可能所有功能都可以使用,然后我参考了 readme 中的推荐配置编写了服务端和客户端的 config.json 并成功实现翻墙(reality)

---

以下是请教的问题:

1. 从背景中是否可以得出结论: go的编译环境的系统的版本和使用编译产物的系统的版本不一致也可以运行? 即 go 的编译产物具有完美的向后兼容性?(大概率不可能)
2. 如果1中的结论是 否,那是否可以得出结论:是我的运气比较好,恰好使用了还尚能使用的 xray 的功能,所以表现为正常翻墙?也就是背景中 不完整地可用性 中所说 可能部分功能还可以使用,实际上用其他部分的功能就会 panic ?
3. 如果1中的结论是 否,那以后我在 10.14 上使用 go1.21+ 的编译产物时，是否都是 不完整地可用性？老实说这让我有点心惊胆战的,我使用的大多数 go 编译产物都是 1.21+,他们都不支持 10.14 ,可能哪天碰到特定地逻辑就没办法用了。
4. 在隔壁某 miho* 的 build.yml 中我发现了可以指定使用某个goversion进行编译,那么这种情况是否就可以做到对每个版本的系统(即使它已不受支持)是 完整可用性?虽然使用老版本如 win7 /macos10.*/... 的用户越来越少,还是希望 xray 项目组能考虑一下这种 build 方案,对一些无法升级或无法决定系统版本的使用者来说,不用操心突如其来的不可用问题会让人舒服很多。
5. 编译性语言(golang/rust/...)或者 electron 大多都会在 build 时对系统版本有要求,但他们的编译产物却不一定会遵守这些要求,例如背景中用 go1.23 编译的xray 可以运行在 macos 10.14 (that only support go1.20),很困扰,有的时候可以用有的时候却用不了,所以有什么办法可以确定,即使在不受支持的平台,被编译出来的可执行文件是否可用?只能靠运气去试验吗？

---

期待大佬指点

[maoxikun]

能运行不代表所有代码都能跑通啊，不同的go版本对系统版本肯定是有要求的，兼容win7说白了就是降低go版本，然后代码适应低版本go