go mod init 仅声明模块根路径，不自动修正 import 路径；import 必须严格匹配 go.mod 中的 module 声明（如 example.com/myapp）与目录结构，否则报错。
go mod init 不是“开始用 modules”，而是告诉 Go：“这个目录就是模块根，别再往上找 go.mod 了”。
为什么执行 go mod init 后 import 还报错？
模块初始化只生成 go.mod 文件，不改变 import 路径的合法性。Go 要求 import 语句中的路径必须和 go.mod 里声明的模块名 + 目录结构严格匹配。
- 如果执行了
go mod init example.com/myapp，那import "example.com/myapp/utils"才有效；写import "./utils"或import "utils"会直接报import path does not begin with hostname -
myapp/utils/目录下不能有func main()，否则 Go 会把它当可执行程序而非可导入包 - 常见陷阱：项目放在
$GOPATH/src下但GO111MODULE=on，Go 会完全忽略该路径，且不提示原因
模块名到底该怎么起？
模块名不是 URL，也不是本地路径，而是一个命名空间标识符——它要唯一、稳定、可读，且后续所有 import 都得按它来写。
- 推荐用实际托管地址（如
github.com/username/project），即使还没 push 上去也没关系 - 绝对不要用
./mylib、../common这类相对路径当模块名，Go 会当作非法导入处理 - 模块名里带
v2等主版本号时，对应代码必须放在/v2子目录下，否则go build会找不到包
go mod init 后下一步必须做什么？
不是立刻 go get，而是先确认所有 .go 文件里的 import 是否都指向合法路径。否则后续 go mod tidy 会失败。
- 运行
go mod tidy前，确保没有拼错 import：比如githib.com/xxx（少个 u）、Ginvsgin大小写不符 -
go mod tidy报no required module provides package，90% 是 import 路径和模块名/目录结构对不上，不是网络问题 - 临时验证？删掉
go.mod和go.sum，设GO111MODULE=off再试一次构建——但这只是诊断手段，不能作为长期方案
最易被忽略的一点：go mod init 只解决“从哪开始算模块”，不解决“别人怎么 import 你”。模块名一旦写进 go.mod 并被他人引用，就几乎无法安全更改——改名等于换包。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
