答案是go mod init只生成go.mod文件，不创建任何Go源文件；go run需至少一个含package main和func main()的.go文件才能执行。
go mod init 之后为什么 go run 报错 “no Go files in current directory”
不是没写代码，而是 go mod init 只生成 go.mod，不创建任何 Go 源文件。Go 工具链在执行 go run 时会扫描当前目录下所有 .go 文件，找不到就直接报这个错误。
- 必须手动创建至少一个
.go文件（比如main.go），且其中要包含package main和func main() -
go run默认只运行当前目录下的.go文件；如果文件在子目录里，得显式指定路径，例如go run cmd/app/main.go - 别把
go.mod放在空目录里初始化后就以为万事大吉——它只是声明“这里是个模块”，不等于“这里有可执行代码”
GOROOT 和 GOPATH 在模块化时代还用配吗
GOROOT 几乎总是自动识别的，除非你手动解压 Go 到非标准路径；GOPATH 在 Go 1.16+ 已完全退场，仅保留历史兼容性，现代项目根本不需要它。
-
GOROOT：安装 Go 后，go env GOROOT通常能正确输出（如/usr/local/go）；只有当你把 Go 解压到自定义路径且未加入PATH时，才需手动设GOROOT -
GOPATH：Go 1.13 起默认启用模块模式（GO111MODULE=on），GOPATH不再影响依赖查找或构建逻辑；它只在旧式 GOPATH 模式下才起作用，现在连go get都默认走模块了 - 真正要关注的是
GOBIN：如果你希望go install的二进制文件全局可用，就得确保$GOBIN在PATH中；否则它默认落到$HOME/go/bin，而该路径未必已加入PATH
go.sum 文件频繁变动，是不是依赖被污染了
不一定。只要 go.sum 变动是伴随 go mod tidy 或 go get 触发的，就是正常行为；异常变动往往来自手动编辑、跨环境同步遗漏或代理缓存不一致。
-
go.sum记录的是每个依赖模块的校验和（checksum），每次新增/升级依赖都会追加新行，旧版本不会被删——所以它天然“只增不减” - 如果发现同一 commit 下
go.sum在不同机器上内容不同，大概率是 GOPROXY 设置不一致（比如一台走官方 proxy，一台直连 GitHub） - CI 环境中务必设置
GOPROXY=https://proxy.golang.org,direct，避免因网络波动导致 checksum 校验失败或拉取不同快照 - 切勿手动删
go.sum；若真要重置，先go clean -modcache，再go mod tidy
internal 包被外部模块 import 成功，但编译时报错
Go 编译器对 internal 的检查发生在 build 阶段，不是 import 阶段——也就是说，import 语句能通过语法检查，但链接时会拒绝非法引用。
立即学习“go语言免费学习笔记（深入）”；
- 错误信息通常是：
import "xxx/internal/yyy" is not allowed by which package xxx imports it - 关键判断依据是目录层级：
project/internal/utils只能被project/...下的包导入，不能被project/cmd或兄弟目录如project/api直接导入（除非它们同属project的子路径） - 常见误操作：把
internal放在pkg或lib这类通用目录下，结果整个项目根目录外的其他模块都能 import 它——这违背了internal的设计本意 - 验证方式：运行
go list -f '{{.ImportPath}}' ./...，看哪些包实际引用了internal，再对照路径规则人工核对
internal 的限制、go.mod 的位置、甚至 cmd/ 和 pkg/ 的划分，都不是约定俗成，而是 Go 工具链靠路径字符串硬编码识别的规则。 
