go环境搭好只需go run能运行，但开发效率取决于环境变量、模块代理和项目结构：goroot需正确加入path，go111module必须为on，goproxy应设为https://goproxy.cn,direct，导入路径须严格匹配go.mod中声明的module名。
Go 环境能跑 go run main.go 就算搭好了，但真正影响后续开发效率的，是环境变量、模块代理和项目结构这三处。
go version 没输出？先查 GOROOT 和 PATH
终端敲 go version 报 “command not found”，不是没装好，而是系统根本找不到 go 二进制。Mac/Linux 上常见原因是 PATH 没包含 Go 的安装路径；Windows 则常因安装时勾选了 “Add to PATH” 却被杀毒软件拦截。
- Mac 用 Homebrew 安装后，
go默认在/opt/homebrew/bin/go（Apple Silicon）或/usr/local/bin/go（Intel），需确认该路径已加入$PATH - Linux 手动解压安装时，
GOROOT必须显式设为解压目录（如/usr/local/go），且$GOROOT/bin要加进PATH - Windows 用户如果用 MSI 安装包，建议重装并手动勾选 “Add Go to PATH”，别信默认选项
go mod tidy 总卡住？GOPROXY 和 GO111MODULE 必须开
新建项目后执行 go mod init 再 go mod tidy 却拉不下依赖，大概率是模块功能没启用或代理不可用。Go 1.16+ 默认开启模块，但某些旧 shell 配置或 CI 环境仍可能关闭它。
- 运行
go env -w GO111MODULE=on强制启用模块管理（不加-w只查不设） - 国内用户必须配代理：
go env -w GOPROXY=https://goproxy.cn,direct，direct是 fallback，避免私有库无法拉取 - 如果项目里已有
go.mod但内容为空或版本混乱，删掉重来比硬修更省时间
为什么 go run 能跑，go build 却报错找不到包？
这不是环境问题，而是项目结构没对齐 Go 的导入规则。Go 不认相对路径，所有 import 都按 go.mod 里的 module 名 + 子目录路径解析。
- 假设
go mod init github.com/you/project，那import "github.com/you/project/internal/handler"才合法，不能写import "./internal/handler" -
cmd/下的main.go必须用完整 module 路径导入其他包，哪怕它们在同一仓库 - 别把第三方库代码直接拷进
vendor/——go mod vendor自动生成才可靠，手改易出错
GOROOT 和 GOPATH 还要手动设吗？
Go 1.16+ 后，GOROOT 通常自动识别，不用设；GO111MODULE=on 时，GOPATH 对依赖管理已无作用，只影响 go install 生成的二进制存放位置（即 $GOPATH/bin）。
- 如果你用
go install安装命令行工具（比如gofumpt），记得把$GOPATH/bin加进PATH，否则终端找不到命令 - 现代项目几乎不用
GOPATH/src目录结构，go mod全局缓存依赖到$GOCACHE，跟GOPATH无关 - 唯一需要碰
GOPATH的场景：你非要用go get（不推荐）或某些老工具链要求它存在
最常被忽略的是：go env 输出里 GOPROXY 显示正常，但实际请求被公司防火墙拦截——这时 curl -v https://goproxy.cn 比看文档更管用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
