17370845950

Go 1.11+ 默认支持模块，需在项目根目录执行 go mod init example.com/myproject 初始化生成 go.mod 文件以启用模块模式，模块路径须合法且建议与仓库地址一致，否则可能导致依赖解析失败或退回到 GOPATH 模式。

Go 1.11+ 默认支持模块，但需显式初始化

Go 模块（Go Modules）从 Go 1.11 开始作为实验特性引入，Go 1.13 起成为默认依赖管理机制。**不需要全局开关或配置项来“启用”模块模式**——只要项目根目录下存在 go.mod 文件，go 命令就会自动进入模块模式；否则默认使用 GOPATH 模式（已废弃）。

如何正确初始化一个模块：使用 go mod init

在项目根目录执行命令生成 go.mod，这是开启模块模式的唯一必要动作：

go mod init example.com/myproject

说明：

• example.com/myproject 是模块路径（module path），应尽量与未来代码可导入路径一致，不能是本地路径如 ./myproject 或 /home/user/myproject
• 若当前目录在 $GOPATH/src 下，go mod init 仍会创建模块——它不关心是否在 GOPATH 内
• 模块路径不必真实存在，但建议与实际仓库地址匹配（如 GitHub 地址），便于他人 go get
• 执行后会生成最小化的 go.mod 文件，包含 module 和 go 版本声明

常见误操作导致模块未生效

即使运行了 go mod init，以下情况仍会让命令退回到 GOPATH 模式或报错：

• 当前工作目录不在模块根目录（即没有 go.mod 的父目录中执行 go build）
• 设置了环境变量 GOPATH 且当前路径恰好落在 $GOPATH/src 下，但未运行 go mod init —— 此时 Go 会优先走旧逻辑
• 模块路径含非法字符（如空格、中文、下划线开头）、或以 golang.org / go.dev 等保留域名开头
• 执行 go get 时用了 -d 但没加 -u，或用了过时的 go get github.com/xxx/yyy（无 @version）导致版本解析失败

验证模块是否生效：看命令输出和 go.mod 变化

模块模式启用后，典型表现有：

• go bui

  

  ld / go run 不再读取 $GOPATH/src 下的同名包，而是按 go.mod 中记录的版本拉取
• 首次 go run main.go 会自动写入依赖到 go.mod，并生成 go.sum
• go list -m all 可列出当前模块及所有直接/间接依赖及其版本
• go env GO111MODULE 输出为 on 表示强制启用模块（一般无需设置），auto 是默认值（根据是否有 go.mod 自动切换）

真正容易被忽略的是：模块路径一旦写入 go.mod，后续 go get 或重构 import 路径时，必须同步更新 module 行，否则会出现 “import path does not contain a dot” 或版本解析混乱。