Go语言中GO111MODULE等环境变量名称的始末

GO111MODULE是什么意思？怎么来的？什么用？为什么这样子？

这是一个非常经典的 Go 语言问题。例如要通过原码的方式安装minio可以这样子写:

GO111MODULE=on go install github.com/minio/minio@latest # https://hub.docker.com/r/minio/minio#install-from-source

一句话总结

GO111MODULE 是一个在 Go 语言从旧版 GOPATH 模式向新版模块（Module） 模式过渡期间引入的“开关”环境变量，用于控制 Go 工具链的行为模式。它的核心作用是决定 go 命令是使用传统的 GOPATH 模式还是新的 Go Modules 模式来管理依赖。

1. 是什么意思？怎么来的？

它的名字就揭示了它的来历：

• GO：代表 Go 语言。
• 111：代表 Go 1.11 这个版本。
• MODULE：代表 Go Modules 特性。

所以，GO111MODULE 字面意思就是“在 Go 1.11 版本中引入的模块开关”。

历史背景： 在 Go 1.11 版本（2018年8月发布）之前，Go 项目严重依赖 GOPATH 来管理代码和依赖。这种方式有很多不便之处，比如必须把代码放在特定目录下、依赖的版本控制非常弱等。

为了解决这些问题，Go 团队在 1.11 版本正式引入了 Go Modules 作为实验性功能。这是一个颠覆性的变化，为了平滑过渡，他们需要一种方式让用户自己选择使用新模式还是旧模式。于是，GO111MODULE 这个“开关”就诞生了。

2. 有什么用？（它的三个值）

GO111MODULE 可以设置为三个值：off, on, auto（默认值）。

a) GO111MODULE=off

• 行为：强制关闭 Go Modules 功能。
• 依赖管理：Go 命令会始终使用传统的 GOPATH 模式。
• 使用场景：
  • 你正在维护一个非常老旧的、无法迁移到 Go Modules 的项目。
  • 你希望所有行为都和 Go 1.10 及之前版本完全一致。
• 注意：在此模式下，即使你的项目目录下有 go.mod 文件，也会被忽略。

b) GO111MODULE=on

• 行为：强制开启 Go Modules 功能。
• 依赖管理：Go 命令会始终使用 Modules 模式，完全忽略 GOPATH。
• 使用场景：
  • 你明确希望所有项目都使用 Modules 进行管理。
  • 你的代码可以放在任何路径下（比如 ~/Desktop/my-project），不再需要放在 GOPATH/src 下。
  • 从 Go 1.16 开始，这已成为默认行为（详见下文）。

c) GO111MODULE=auto（默认值）

• 行为：“自动”模式。这是最常用也是最开始的设计模式。
• 逻辑：
  1. 如果当前目录或其任意父级目录中存在一个 go.mod 文件，那么就启用 Go Modules 模式。
  2. 否则，回退到旧的 GOPATH 模式。
• 使用场景：这是过渡期的理想选择。对于位于 GOPATH 外的项目或已有 go.mod 的项目，自动启用新特性；对于传统的 GOPATH 内的项目，则保持旧行为，确保兼容性。

3. 为什么这样子？（设计哲学与演进）

这个设计体现了 Go 团队一贯的务实和渐进式演进哲学：

1. 平滑过渡：直接强制切换会破坏无数现有项目。提供一个开关，让社区和生态（如 IDE、CI/CD 工具）有时间逐步适应。
2. 向后兼容：确保所有在 Go 1.10 下能工作的代码，在 Go 1.11 中通过设置 GO111MODULE=off 后依然能正常工作。
3. 用户可控：将选择权交给开发者，而不是强加一种方式。

现状与未来（非常重要！）

随着 Go Modules 的成熟，这个过渡期已经基本结束。

• Go 1.16（2021年2月）：默认行为将 GO111MODULE 从 auto 改为 on。这意味着，无论项目是否在 GOPATH 内，只要 Go 版本 >= 1.16，它都会强制使用 Modules 模式。你仍然可以显式地设置 GO111MODULE=off 来禁用。
• Go 1.18 及以后：Go Modules 已经成为官方的标准依赖管理方案。GOPATH 模式已被弃用。
• Go 1.21：在最新版本中，即使你设置 GO111MODULE=off，很多命令（如 go install）依然会默认启用 module 模式。这强烈表明旧模式已不再被推荐。

结论：对于现在（2024年及以后）开始的所有新项目，你应该且必须使用 Go Modules。可以完全忘记 GOPATH 和 GO111MODULE 的存在，因为默认行为就是你想要的。

如何查看和设置？

# 查看当前设置（如果没设置，输出为空，即使用默认行为）
go env GO111MODULE
# 临时设置（仅当前终端窗口有效）
set GO111MODULE=on        # Windows
export GO111MODULE=on     # Linux/macOS
# 永久设置（推荐）
go env -w GO111MODULE=on

总结

关于go get和go install

GO111MODULE=on go install github.com/minio/minio@latest 和 go get github.com/minio/minio@latest 两种方式有什么不一样？

在 Go Modules 时代（尤其是 Go 1.16 及以后版本），GO111MODULE=on go install 和 go get 的行为确实有显著区别。以下是它们的核心差异和适用场景：

1. GO111MODULE=on go install github.com/minio/minio@latest

行为特点

• 仅安装二进制：将 github.com/minio/minio 的最新版本编译为二进制文件，安装到 $GOPATH/bin（或 $GOBIN）目录下。

• 不修改 go.mod：不会在你的当前项目（如果有）的 go.mod 中添加任何依赖记录。

• 独立操作：适合全局安装工具，与项目依赖管理完全解耦。

适用场景

• 当你只是想全局安装一个可执行工具（如 minio 服务器客户端）时使用。

• 例如：安装 golangci-lint、staticcheck 等开发工具。

示例

# 安装最新版 minio 客户端到 $GOPATH/bin
GO111MODULE=on go install github.com/minio/minio@latest
# 安装后直接运行
~/go/bin/minio --version

2. go get github.com/minio/minio@latest

行为特点（Go 1.16+）

• 添加依赖：如果当前目录是 Go 项目（有 go.mod 文件），会将 minio 作为依赖添加到 go.mod 中。

• 不安装二进制：默认不会将 minio 的可执行文件安装到 $GOPATH/bin（除非该包是 main 包且你显式要求安装）。

• 版本管理：通过 @latest 明确指定版本，遵循 Go Modules 的版本控制规则。

适用场景

• 当你想将某个库或工具作为当前项目的依赖时使用。

• 例如：项目中需要引入 github.com/stretchr/testify 测试库。

示例

# 进入你的项目目录
cd ~/projects/my-go-app
# 将 minio 作为依赖添加到当前项目的 go.mod 中
go get github.com/minio/minio@latest

关键区别总结表

历史背景补充

• Go 1.16 之前：go get 兼具“安装二进制”和“添加依赖”两种功能，行为混乱。

• Go 1.16 之后：官方明确分离职责：

  • go install pkg@version → 仅安装二进制
  • go get pkg@version → 仅管理依赖

• Go 1.18+：更推荐用 go install 安装工具，go get 仅用于项目依赖管理。

常见问题

Q：为什么我用 go get 安装工具时没有生成二进制？

A：从 Go 1.16 开始这是预期行为。若需安装二进制，请改用：

go install github.com/minio/minio@latest

Q：两者都能用时的选择原则？

• 需要全局工具 → go install

• 需要项目依赖 → go get

Q：GO111MODULE=on 现在还需要显式指定吗？

A：Go 1.16+ 后不需要（默认已开启）。以下两种写法等价：

go install github.com/minio/minio@latest         # 推荐
GO111MODULE=on go install github.com/minio/minio@latest  # 冗余

总结

• 安装工具 → go install pkg@version

• 添加依赖 → go get pkg@version

• 在 Go 1.16+ 的现代工作流中，go install 和 go get 已明确分工，不再混淆。