答案是项目未初始化模块，需在根目录执行 go mod init。go 1.16+ 默认启用模块模式，但要求存在 go.mod 文件；否则即使环境配置正确，go build/run 也会报错。正确做法是在 main.go 所在目录运行 go mod init example.com/myapp，再执行 go mod tidy 拉取依赖。
不是环境没装好，是项目没“认领”模块系统 —— 你缺的不是 Go，是一个 go mod init。
为什么 go build / go run 直接报 go.mod file not found
Go 1.16+ 默认启用模块模式（GO111MODULE=on），但前提是：当前目录或任意父目录存在 go.mod。如果只是新建了个 main.go 就直接执行，Go 会拒绝加载任何外部包（比如 github.com/gin-gonic/gin），甚至不让你 go build，因为整个项目没被声明为一个模块。
- 这不是 GOPATH 旧路径问题，也不是代理或网络问题
- 即使
go version正常、GOROOT/GOPATH都设对了，照样报这个错 - IDE（如 Goland、VS Code）里点运行失败，命令行
go run main.go也失败，根源一致
怎么用 go mod init 正确初始化项目
必须在项目根目录（即放 main.go 的那个文件夹）下运行，且模块名不能随意填空或用中文/空格。
- 模块名建议用可解析的域名前缀，例如：
go mod init example.com/myapp（哪怕不真托管在 example.com） - 如果只是本地练手，用
go mod init myapp也行，但避免用.、test、02test这类易触发解析歧义的名字 - 执行后会生成
go.mod（含module声明和 Go 版本）和空的go.sum - 之后再
go run main.go或go build才会真正开始解析 import 并拉依赖
GO111MODULE 设成 auto 还是 on？
现在推荐统一设为 on，避免路径判断带来的不确定性。
- 查当前值：
go env GO111MODULE - 强制开启：
go env -w GO111MODULE=on -
auto模式下，若项目在$GOPATH/src内，Go 会自动退回到 GOPATH 模式（忽略go.mod），导致“有文件却不用”的诡异现象 - 设为
on后，Go 完全无视GOPATH/src结构，只认go.mod所在位置
常见误操作与修复动作
很多人跑完 go mod init 还是报错，往往卡在这几个地方：
- 终端当前路径不在项目根目录 ——
ls go.mod看不见就说明没进对目录 - 项目目录嵌套在
$GOPATH/src下（例如~/go/src/myproject）—— 移出来，放到~/projects/myproject更稳妥 - 用 IDE 运行时工作目录不对 —— Goland 要关掉「Use module path」选项（Settings → Go → Go Modules → ✅ Uncheck “Enable Go modules integration”），否则它会绕过你本地的
go.mod -
go.mod生成后仍提示找不到包 —— 运行go mod tidy，它会自动补 import 的包并写入go.mod
模块初始化这件事本身很简单，但容易被当成“环境配置问题”去调 GOPATH 或重装 Go —— 实际上，只要确保 go.mod 在对的位置、GO111MODULE=on、且没卡在 GOPATH/src 里，99% 的 go.mod file not found 就当场消失。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
