根本原因是模块上下文缺失：go build 要求当前工作目录必须是有效模块根（含 go.mod），且所有 import 路径须能映射到该模块或其显式依赖的模块；若在子目录执行、模块名与 import 路径不一致、或 gopath/src 下代码未 replace 声明，则报“cannot find module providing package”。
Go 1.11 之后，go mod 不再是“可选插件”，而是编译行为本身的一部分——没有模块上下文，go build 会拒绝解析相对导入、忽略 vendor/、甚至无法正确识别本地包路径。
go mod init 后，为什么 go build 还报 “cannot find module providing package”？
这不是路径问题，而是模块感知缺失的典型症状。Go 编译器在模块模式下，所有导入路径都必须能映射到某个已声明的模块根（即 go.mod 所在目录及其子目录），且该模块必须被当前工作目录的模块显式依赖或直接包含。
- 常见错误：在子目录里执行
go build，但go.mod在父目录——Go 不会向上递归查找模块根，除非你用go work use或明确cd到模块根目录 - 错误现象：
import "myproj/internal/handler"报错，即使文件存在——因为myproj没有在当前模块的go.mod中声明为模块路径，或路径拼写与module myproj不一致 - 验证方式：运行
go list -m，输出第一行必须是你期望的模块名；若显示command-line-arguments，说明当前不在有效模块上下文中
GO111MODULE=on 时，GOPATH/src 下的代码还能被 import 吗？
不能。启用模块模式后，Go 工具链完全绕过 GOPATH 的 src 查找逻辑。所有导入都基于模块路径解析，而非文件系统路径。
-
import "github.com/user/repo"→ 从$GOPATH/pkg/mod或 proxy 下载并缓存 -
import "mycompany/core"→ 必须在当前模块的go.mod中有replace mycompany/core => ./internal/core，或该路径属于当前模块自身（即module mycompany/core） - 旧习惯陷阱：把代码扔进
GOPATH/src就以为能被引用——模块模式下这毫无意义，go build根本不会看那里
为什么 go run main.go 和 go build -o bin/app . 行为不一致？
关键差异在于工作目录和模块根判定。前者以 main.go 所在目录为起点推导模块；后者以当前 shell 工作目录为准，且要求该目录下存在 go.mod 并能覆盖所有被构建的包。
- 场景：项目结构为
cmd/app/main.go，go.mod在项目根目录。若你在cmd/app/下执行go run main.go，Go 会尝试向上找go.mod，通常成功；但若执行go build -o ../bin/app .，它只扫描当前目录（cmd/app）下的包，而该目录下没有go.mod，就会失败 - 可靠做法：始终在模块根目录执行构建命令；或用
go build -o bin/app ./cmd/app显式指定包路径 - 副作用：
go run可能临时创建go.mod（如果找不到），导致后续go build行为突变——务必检查是否意外生成了新模块文件
模块化不是配置开关，它是 Go 编译器读取源码前的第一道解析层。任何脱离 go.mod 路径体系的导入，哪怕文件物理存在，都会在编译早期被拦截。最易被忽略的是：go mod init 生成的模块名必须与实际 import 路径严格一致，差一个字符，整个依赖图就断了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
