必须先清理GOPATH和GOROOT再谈模块，因为Go工具链会根据项目是否位于$GOPATH/src下自动降级回GOPATH模式，即使GO111MODULE=on；GOROOT与GOPATH绝不能相同，否则标准库与本地同名包冲突；go mod init定义的模块路径决定所有import的绝对根路径，internal目录是编译期强制隔离机制，仅限本模块内使用。
Go 环境搭建本身不直接“教”你包管理，但它是理解包管理机制的物理前提——没有清晰的环境边界，go mod 就像在雾里跑命令，所有 import 错误、cannot find package、undefined: xxx 都会失去上下文。
为什么必须先清理 GOPATH 和 GOROOT 再谈模块
很多人卡在“明明写了 go mod init，却还是走 GOPATH 查找路径”，根本原因是：Go 工具链会根据当前目录是否在 $GOPATH/src 下，自动降级回 GOPATH 模式（即使 GO111MODULE=on）。这不是 bug，是兼容性策略。
-
go env GOPATH输出的路径下，如果当前项目在$GOPATH/src/xxx里，go build会无视go.mod，强行按旧规则解析 import 路径 -
GOROOT和GOPATH绝对不能是同一路径，否则标准库包（如fmt）和你本地写的同名包会冲突，报错类似import cycle not allowed - 验证方式：运行
go env -w GO111MODULE=on后，再执行go list -m—— 如果输出command-line-arguments而不是你的模块名，说明仍处于 GOPATH 模式
go mod init 的路径参数决定 import 根路径
go mod init 不只是生成一个文件，它定义了整个模块的“导入根”。后续所有 import 语句里的路径，都是相对于这个模块路径展开的，而不是文件系统路径。
- 比如你在
/home/user/myproj下执行go mod init example.com/myproj，那么import "example.com/myproj/internal/handler"才合法；写成import "./internal/handler"或import "myproj/internal/handler"全部报错 - 模块路径不必对应真实域名，但必须全局唯一（尤其当你将来要发布到私有仓库时），建议用
github.com/username/repo这类格式，避免用localhost或空字符串 - 如果初始化后想改模块路径，不能只改
go.mod里的module行——你还得同步改所有import语句，否则编译失败
internal 目录不是语法糖，而是编译期强制隔离
internal 是 Go 工具链硬编码识别的关键词，不是约定俗成的文件夹名。它的作用是在编译阶段阻止跨模块引用，哪怕路径拼对了也不行。
立即学习“go语言免费学习笔记（深入）”；
- 假设项目结构为：
myapp/ ├── go.mod (module myapp) ├── internal/service/db.go └── cmd/server/main.go，那么cmd/server/main.go可以import "myapp/internal/service"，但外部项目otherapp即使import "myapp/internal/service"也会在go build时报错：use of internal package not allowed - 这个限制只发生在模块边界上：同一模块内
internal下的包可以互相 import；不同模块之间不行。它和private关键字无关，也不依赖首字母大小写 - 别把
internal当作“放工具函数的地方”——它本质是“防误用的围栏”。真正该复用的逻辑，应该放在pkg/下，并导出大写标识符
真正容易被忽略的是：模块路径一旦写进 go.mod，就锁定了整个项目的 import 体系。改路径不是改配置，是重构；而 internal 的生效与否，完全取决于你是否在正确的模块上下文中执行 go build —— 这些细节不会报错提示，只会让 import 看似“随机失效”。
