正常。从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可能返回空或默认路径（如
$HOME/go），但只要 go mod init 能成功、go run 能执行，就说明环境已就绪。
- 检查模块是否启用：
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 工具链（
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（显式指定入口），比
go run . 更可控，尤其在多 main 共存时。
真正麻烦的不是搭建环境，而是项目长大后，internal 和 pkg 边界模糊、go mod 依赖版本漂移、cmd/ 下多个服务共享配置却各自 copy-paste —— 这些问题，第一天建目录时就埋下了。
