Go 1.16+ 不需也不该配置 GOPATH，因其仅用于 $GOPATH/bin 存放 go install 工具，项目依赖由 GO111MODULE=on 的模块模式管理；关键是要确保 GO111MODULE=on 且 go mod init 的模块路径与 import 路径严格一致。
Go 1.16 之后，你不需要、也不该手动规划传统 GOPATH 目录结构（src/pkg/bin）——它已过时，强行套用反而导致 go mod tidy 报错或依赖无法解析。
为什么 ~/go/src/github.com/xxx/yyy 这种路径现在会出问题？
因为模块模式（GO111MODULE=on）启用后，Go 不再从 GOPATH/src 下查找包，而是直接读取项目根目录的 go.mod。如果你仍把项目放 ~/go/src/... 里，又用 go mod init myproj 初始化，就会出现：
-
no required module provides package github.com/xxx/yyy（导入路径和模块名不匹配） -
go get失败，提示“cannot find module providing package” - VS Code 或
gopls识别不到依赖，跳转失效
根本原因：模块名（go mod init 后写的那个字符串）必须与你实际 import 的路径一致，而不再受物理路径约束。
go mod init 的模块名到底该怎么写？
模块名不是项目文件夹名，而是未来别人 import 你包时的完整路径前缀。写错会导致所有工具链行为异常。
立即学习“go语言免费学习笔记（深入）”；
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 推荐格式：
github.com/yourname/projectname（哪怕还没 push 到 GitHub） - 避免：
myapp、./myapp、file:///path/to/myapp—— 这些会让go list和go mod graph失效 - 私有域名可用：
git.internal.company.com/team/project，但需配置GOINSECURE=git.internal.company.com或 Git URL 重写规则 - 验证方式：
go list -m应输出你写的模块名，且import "github.com/yourname/projectname/pkg/util"能被正确解析
现代 Go 项目该有哪些目录？哪些是真有用？
没有强制规范，但成熟项目（如 etcd、prometheus）普遍采用以下结构，兼顾可维护性与工具兼容性：
-
cmd/：每个子目录一个main.go，例如cmd/api/main.go、cmd/cli/main.go—— 这是go build -o的标准目标位置 -
internal/：存放仅本项目使用的私有包，go工具会阻止外部模块 import 它们，防止接口泄露 -
pkg/（可选）：存放可被其他项目复用的公共包，命名需明确，如pkg/auth、pkg/httpx -
api/或proto/（如用 gRPC）：存 OpenAPI spec 或.proto文件，配合//go:generate自动生成代码 - 根目录必须有：
go.mod、go.sum、.gitignore；Makefile或build.sh强烈建议加
别再建 src/ 子目录 —— 它在模块模式下毫无意义，只会干扰 IDE 和 go list 的路径推导。
那 GOPATH 还要不要设？设成啥？
不用设，也不该覆盖默认值。Go 1.21+ 安装后 go env GOPATH 返回空或 $HOME/go 都正常。
-
GOPATH现在只用于go install生成的二进制工具存放位置（即$GOPATH/bin），比如gopls、stringer -
PATH中需包含$GOROOT/bin（Go 自带命令）和$GOPATH/bin（你go install的工具） - 执行
go install github.com/cpuguy83/go-md2man@latest后，生成的go-md2man就在$GOPATH/bin下，可直接调用 - 手动
export GOPATH=...只有在你要自定义工具安装路径时才有用，99% 场景不需要
真正关键的是：确保 go env GO111MODULE 输出 on，且新建项目能 go mod init + go run main.go 成功 —— 其他都是次要的。
