Go 1.16+ 必须用 go mod init 初始化模块，GOROOT 需手动配置为真实 Go 安装路径（含 bin/go），模块名须符合导入路径规则（如 github.com/user/name），工作目录必须为含 go.mod 的项目根目录。
直接用 go mod init 初始化就行，不用管 GOPATH —— Go 1.16+ 默认强制启用 modules，硬套旧式 $GOPATH/src/xxx 结构反而会卡在依赖解析、go run 报错、IDE 识别失败上。
GOROOT 指向错误是 go run 失败的第一原因
很多“项目建好了但跑不起来”的问题，根源不在代码或模块名，而在 Goland（或终端）根本没连上真正的 Go 安装。Goland 不会自动猜对路径，尤其当你装过多个版本、或用包管理器（如 Homebrew、scoop）安装时。
- 打开
File → Settings → Go → GOROOT（macOS 是Go → GOROOT），手动选中你本地 Go 的根目录，比如/usr/local/go或C:\Go - 进去确认该路径下存在
bin/go（Linux/macOS）或bin\go.exe（Windows），否则 Goland 会标红 “Invalid Go SDK” - 别信“自动探测”——它可能选了 /opt/homebrew/bin/go 这类软链，而实际
go version输出的是 1.20，Goland 却加载了 1.18 - 终端里执行
which go和go version，和 Goland 里显示的 GOROOT 对一遍，必须一致
go mod init 的模块名不能随便填
模块名不是项目文件夹名，也不是 main，它本质是将来被其他项目 go get 引用时的导入路径。填错会导致依赖无法解析、replace 失效、CI 构建失败。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 推荐格式：
github.com/yourname/projectname或example.com/myapp—— 域名可虚构，但要符合 Go 的导入规则 - 绝对不要填
main、.、空字符串或纯数字，否则go list -m会报错，go get ./...也走不通 - 如果已经误填，不用删项目：进项目根目录，删掉
go.mod，再运行go mod init github.com/yourname/correct-name - Goland 新建时选 “Go Module”，它会自动帮你跑这步；若选了 “Empty Project”，就靠手动补救
工作目录错位会让 go run 直接找不到包
go run main.go 看似简单，但它隐式依赖当前目录下有有效的 go.mod，且 Go 工具链能从该目录向上找到模块根。Goland 的 Run Configuration 默认工作目录（Working directory）容易设成 ~/Downloads 或用户主目录，而不是项目根。
立即学习“go语言免费学习笔记（深入）”；
- 右键
main.go → Run 'main.go'后，点右上角 ▽ → Edit Configurations → 检查 Working directory 是否为项目根目录（即含go.mod的那个文件夹） - 终端里先
cd进项目根，再执行go run main.go；如果报cannot load fmt，基本就是 GOROOT 错了，不是代码问题 -
go list -m必须输出你的模块名，否则整个 modules 系统没激活，go get、go test全部失效 - 别在子目录里执行
go run—— 即使main.go在那里，Go 也会尝试从当前目录找go.mod，找不到就退化成 GOPATH 模式（已废弃）
真正卡住人的从来不是语法或框架，而是 go.mod 文件存在但没被识别、GOROOT 指向一个“看起来像 Go 实际是旧版 stub”的路径、或者 Goland 的 Run Configuration 默默用了错误的工作目录 —— 这三处不动手验证，光改代码没用。
