go环境问题根源在于gopath、goroot和模块初始化未对齐：goroot不应手动设置（go 1.16+自动识别），go mod init须在项目根目录执行，go111module应设为on，编译优化可禁用cgo并去除调试符号。
Go 环境搭不对，go run 都会报 command not found 或 cannot find package —— 根本不是代码问题，是 GOPATH、GOROOT 和模块初始化三者没对齐。
确认 GOROOT 是否被手动污染
很多人从官网下载二进制包后，直接解压到 /usr/local/go，却在 ~/.bashrc 或 ~/.zshrc 里重复写 export GOROOT=...。这反而会覆盖 Go 自带的 GOROOT 探测逻辑，尤其在多版本共存时引发 go: cannot find main module。
- 删掉所有显式
export GOROOT=...行（Go 1.16+ 默认自动识别安装路径） - 运行
go env GOROOT，输出应为实际安装路径（如/usr/local/go），且与which go所在目录一致 - 若输出为空或错误路径，说明 shell 初始化文件干扰了 Go 的自发现机制
go mod init 必须在项目根目录执行
新手常把 go mod init myapp 放在任意子目录下运行，结果生成的 go.mod 文件里模块路径变成 myapp/subdir，后续 go build 会找不到入口包。
- cd 到你打算放
main.go的最外层目录（比如~/projects/myapp），再执行go mod init myapp - 模块名不必和文件夹名完全一致，但必须能唯一标识项目；建议用域名反写（如
github.com/you/myapp），避免本地导入冲突 - 如果已有
go.mod但路径不对，删掉它，回到正确目录重试 —— Go 不会自动修正已存在的模块声明
编译速度慢？关掉 cgo 和调试符号
go build 默认启用 cgo 并保留 DWARF 调试信息，这会让二进制体积翻倍、链接变慢，尤其在 CI 或嵌入式目标上明显。
- 纯 Go 项目（无 C 依赖）加
-gcflags="all=-l -s"去除调试符号，-ldflags="-s -w"去除符号表和 DWARF - 禁用 cgo：
CGO_ENABLED=0 go build -o app，生成静态链接二进制，跨平台部署更稳 - 注意：禁用 cgo 后无法调用
net包的系统 DNS 解析器（会 fallback 到 Go 实现），若依赖getaddrinfo行为需保留
为什么 go run 成功但 go build 失败？
常见于未设 GO111MODULE=on 且项目不在 $GOPATH/src 下 —— go run 会临时启用模块模式，而 go build 严格按环境变量判断是否使用模块。
- 统一设
export GO111MODULE=on（Go 1.16+ 默认开启，但某些旧 shell 会继承关闭状态） - 检查当前目录是否有
go.mod；没有就先go mod init，否则go build会尝试按 GOPATH 模式查找包 - 若仍报
no required module provides package，运行go mod tidy补全依赖，而非手动改go.mod
真正卡住人的从来不是语法，而是 go env 输出里那几行看似无关的路径配置 —— 每次怀疑编译失败，先跑一遍 go env | grep -E "(GOROOT|GOPATH|GO111MODULE)"，比重装 Go 有效得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
