正常。从Go 1.16起模块模式默认启用，GOPATH仅用于安装二进制工具（如$GOPATH/bin），不再存放项目源码；go env GOPATH为空或返回默认路径均属正常，只要go mod init和go run能正常工作即可。

Go 1.21+ 安装后 go env 显示 GOPATH 为空正常吗？

正常。从 Go 1.16 开始，模块模式（GO111MODULE=on）成为默认行为，GOPATH 不再用于存放项目源码——它只保留为 go install 安装二进制工具的路径（如 $GOPATH/bin）。你不需要手动设置 GOPATH，也不该把项目放进去。

验证方式：

go env GOPATH

• 检查模块是否启用：

  go env GO111MODULE

  应输出 on
• GOROOT 指向 Go 安装目录，PATH 中需包含 $GOROOT/bin 和 $GOPATH/bin（后者仅用于 go install 生成的命令行工具）
• 不要用 export GOPATH=... 覆盖默认值，除非你明确需要自定义工具安装位置

新建项目时 go mod init 的模块名怎么写才不踩坑？

模块名不是随便起的项目文件夹名，而是 Go 包导入路径的根。它直接影响依赖解析、版本发布和他人引用方式。

推荐格式：github.com/username/projectname（即使项目暂未开源或托管在 GitHub），原因如下：

• 兼容所有 Go 工具链（go get、go list、IDE 导入提示）
• 避免本地路径（如 myproject 或 ./myproject）导致 go mod tidy 报错 no required module provides package
• 未来迁移到 GitHub/GitLab 时无需修改 go.mod，只需确保远程仓库 URL 匹配即可
• 若使用私有域名（如公司内网），应确保该域名可被 go 命令解析（可通过 GOINSECURE 或配置 git 协议支持）

示例：

mkdir myapp && cd myapp
go mod init github.com/yourname/myapp

标准 Go 项目目录结构里哪些子目录是必须的？

Go 没有强制目录规范，但以下结构被绝大多数成熟项目（如 etcd、prometheus、gin）采用，兼顾可维护性与工具兼容性：

• cmd/：存放可执行入口（每个子目录一个 main.go），例如 cmd/api/main.go、cmd/cli/main.go。这是 go build -o 的常见目标
• internal/：存放仅本项目使用的私有包，go 工具会阻止外部模块 import 它们，防止意外泄露内部实现
• pkg/（可选）：存放可被其他项目复用的公共包（非 internal），命名需清晰（如 pkg/auth、pkg/httpx）
• api/ 或 proto/（如用 gRPC）：存放 OpenAPI spec 或 .proto 文件，配合 go:generate 自动生成代码
• 根目录放 go.mod、go.sum、Makefile、.gitignore 等工程元文件，不放业务逻辑代码

错误示范：src/、lib/、app/ 这类模糊命名会降低团队协作效率，也干扰 gopls 的符号跳转精度。

go run 找不到 main 函数？检查这三个地方

常见报错：no Go files in ... 或 cannot find package "main"，本质是 Go 无法定位到含 func main() 的文件。

• 当前目录下没有 .go 文件，或文件不在 main 包中（确认首行是 package main，不是 package myapp）
• 执行 go run 时未指定文件，且当前目录无 main.go；Go 默认只找 main.go，不会递归扫描整个目录树
• 项目启用了模块，但 go.mod 中模块名与当前路径不匹配（比如你在 /tmp/foo 下执行 go mod init bar，然后 go run . 会失败，因 Go 认为当前路径不属于模块 bar）

安全做法：

go run cmd/api/main.go

真正麻烦的不是搭建环境，而是项目长大后，internal 和 pkg 边界模糊、go mod 依赖版本漂移、cmd/ 下多个服务共享配置却各自 copy-paste —— 这些问题，第一天建目录时就埋下了。