Go 1.17 Go Module变化 | golang配置 GOROOT无法识别已安装的go1.17.8

文章目录 一、Go 1.17 Go Module变化1. Module 依赖图修剪2. 为什么自从Go1.17?以来go.mod中有两个“require”块参考 二、golang配置 GOROOT无法识别已安装的go1.17.8

一、Go 1.17 Go Module变化

美国当地时间2021年8月16日，[Go 1.17版本在经过两个RC版本之后正式发布]！

此版本改进了编译器，具体来说是采用了一种新的函数参数和结果传递方式。官方称此项变化将 Go 程序的性能提升了大约 5%，并将 amd64 平台的二进制包大小减少了大约 2%，未来还计划支持更多平台。

Go 1.17 还增加了对 Windows 上 64 位 ARM 架构的支持，让 Go 开发者能够在更多设备上原生运行 Go。

自从 Go1.11 增加 Go Module 以来，每个版本都在不断改进 Module。Go1.17 也不例外。这次最主要的变化有两点：

Module graph pruning：Module 依赖图修剪Lazy Loading：Module 延迟加载 1. Module 依赖图修剪

新版本还增加了 pruned module graphs 功能。官方对此功能的描述为，当 Modules 在其go.mod文件中指定了go 1.17或更高版本，其 module graph 只包括其他 Go 1.17 模块的直接依赖，而不是其全部的横向依赖。这将有助于避免go.mod为其他不相关的依赖下载或读取文件，从而在日常开发中节省时间。

为了方便演示，我们构建一个这样的例子。

有四个模块：主模块（studymod）和 a、b、c 三个模块，如下图：

module studymod 是我们的项目，它依赖模块 a 中的 x 包，而 x 包依赖模块 b，同时 a 包中的 y 包依赖模块 c。

很显然，对我们的项目 studymod 来说，模块 c 的代码根本没用上。Go 1.17 对 module 的改进主要就是在这种没用上的模块上。

studymod 依赖 a，a 依赖 b 和 c。
但我们知道，studymod 模块实际根本不需要模块 c。

在 Go1.17 以前，如果你不存在 module C 的 package c，程序在编译构建的时候就会报错，提示找不到。

我们再go.mod 中如果，填写

go 1.17

那么 go mod tidy 就会执行依赖图裁剪。 如果我们不想使用依赖图裁剪，我们这里可以写成

go 1.16

2. 为什么自从Go1.17?以来go.mod中有两个“require”块

https://golang.org/doc/go1.17#go-command

因为在Go 1.17中，模块图已更改为启用修剪和延迟加载。第二个require块包含间接依赖项。

参考

Go 1.17 新特性：Module 有哪些变化？
参考URL: https://baijiahao.baidu.com/s?id=1711747830944825242

二、golang配置 GOROOT无法识别已安装的go1.17.8

问题背景：
低版本的goland还需要配置GOROOT，但是在配置go1.17以上的时候就一直报这个错误

The selected directory is not a valid home for Go SDK

解决方法：
思路1： 因为Goland版本和go版本不对应，需要将go版本降低到1.15.15。调整之后，Goland会自动识别出本地安装的GOROOT的路径。

思路2：
1） 执行go version 找到自己安装的详细版本
2） 编辑{GOROOT}/src/runtime/internal/sys/zversion.go文件
D:\go\src\runtime\internal\sys\zversion.go

增加一个自己的版本

const TheVersion = `go1.17.8`

亲测可用！