goroot、gopath、go111module和goproxy必须协同配置：goroot须指向go安装根目录（含bin/src/pkg），不得与gopath重叠；gopath仅为工作区，存放src/pkg/bin；go111module=on强制启用模块模式；goproxy需设为“代理,direct”以支持私有模块和replace指令。
Go 环境不是装完 go version 能跑就算通了——真正影响开发效率的，是 GOROOT、GOPATH、GO111MODULE 和 GOPROXY 四者之间的协作链路。这条链路断在任意一环，都会导致 go build 失败、go get 超时、IDE 识别不到 SDK，甚至 go run 报 “no Go files in current directory” 这类误导性错误。
GOROOT 必须指向真实 bin 目录，且不能与 GOPATH 重叠
很多用户把 Go 解压到 /usr/local/go，却在 /etc/profile 里写错路径，比如漏掉 /bin 后缀，结果 go 命令根本找不到；更隐蔽的问题是：如果 GOPATH（如 $HOME/go）和 GOROOT（如 /usr/local/go）目录结构意外重叠（例如误把项目建在 /usr/local/go/src 下），go build 会静默跳过你的代码，转而编译标准库源码，最终报错 “cannot find package” 或直接无输出。
-
GOROOT应严格等于 Go 安装根目录（含src、pkg、bin子目录），验证方式：go env GOROOT输出必须与which go所在父目录一致 -
GOPATH是纯工作区，只放你自己的代码（src）、依赖（pkg）、工具（bin），绝不能设为/usr/local/go或其子目录 - Linux/macOS 下建议用
export GOROOT=/usr/local/go（手动安装）或export GOROOT=$(brew --prefix go)/libexec（Homebrew 安装）
GO111MODULE=on 是现代 Go 编译链路的开关，不是可选项
Go 1.16+ 默认启用模块模式，但旧系统或某些 Docker 镜像仍可能默认关闭。一旦 GO111MODULE=off，go build 就会退回到 GOPATH 模式：它只认 $GOPATH/src 下的代码，且拒绝编译当前目录下带 go.mod 的项目，报错 “go: modules disabled by GO111MODULE=off” 或干脆忽略 go.mod 导致依赖版本混乱。
- 执行
go env -w GO111MODULE=on永久开启（推荐），或临时用GO111MODULE=on go build - 验证是否生效：
go env GO111MODULE必须输出on，而非空或auto - 若项目已有
go.mod，但go build仍报 “cannot load …: cannot find module …”，大概率是GO111MODULE关闭或当前目录不在模块根下
GOPROXY 必须配对 direct，否则私有模块或本地 replace 会失效
只设 GOPROXY=https://goproxy.cn 看似能解决拉包慢，但会导致两个致命问题：一是公司内网私有仓库的模块无法解析（报 “module …: not found”）；二是 go mod edit -replace 或 replace 指令在 go.mod 中的本地路径映射完全不生效——因为代理强制把所有请求转发出去，根本不会查本地文件系统。
- 正确配置是：
go env -w GOPROXY=https://goproxy.cn,direct，逗号分隔，direct表示“代理查不到时回源，包括本地 replace 和私有域名” - 验证方式：
go env GOPROXY输出应为https://goproxy.cn,direct（不含空格） - 若使用企业 Nexus 或 Artifactory，格式为：
go env -w GOPROXY=https://nexus.example.com/repository/golang-proxy/,direct
极简编译链路：从 go run 到 go build 的真实执行路径
go run main.go 看似一步到位，但它背后触发的是完整模块解析 + 临时构建 + 执行，中间任何环节失败都只报模糊错误。而 go build -o app . 强制走一遍可复现的静态链接流程，更容易暴露环境问题。
- 执行顺序：读
go.mod→ 解析依赖树 → 检查GOPROXY可达性 → 下载/缓存模块 → 编译所有.go文件 → 链接成二进制 - 关键检查点：
go list -m all查依赖是否全 resolve；go build -x显示完整命令行（能看到实际调用的gc编译器路径和参数） - 常见静默失败：当前目录无
main包、main.go文件名拼错、或package main下混入了非main函数但没导出，导致链接器找不到入口点
最常被忽略的其实是 go env -w 写入的是用户级配置，而 CI/CD 或 systemd service 常以 root 或其他用户运行，环境变量未继承——这意味着你在 shell 里 go build 成功，自动化流水线却卡在 “command not found: go”。务必确认目标执行上下文的 $PATH 和 go env 输出完全一致。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
