go version能运行不等于环境可用，必须验证go111module=on、goproxy含direct且可达、$gopath/bin在path中，并能在任意目录用go mod init初始化模块且成功运行含第三方依赖的程序。
go version 能跑，不等于环境可用
看到 go version 输出就关终端，是多数人踩坑的起点。真实项目里报 cannot find package、no Go files in workspace、IDE 提示 “gopls failed to start”，几乎都不是 Go 二进制没装好，而是模块模式、代理、路径三者中至少一个没对齐。
关键判断标准只有一条：能否在任意目录下，用 go mod init 初始化模块，并成功 go run 一个带第三方依赖的程序（比如 golang.org/x/net/html）。做不到，说明环境链路断了。
-
GO111MODULE必须是on，不是auto或空；auto在无go.mod时退化回 GOPATH 模式，CI 和新机器上必翻车 -
GOPROXY不能是默认的https://proxy.golang.org，国内用户设为https://goproxy.cn,direct是底线 -
$GOPATH/bin必须在PATH中——否则go install golang.org/x/tools/cmd/gopls@latest装完也调用不了
go env 里这四个字段必须人工核对
运行 go env 后，别扫一眼就过。直接过滤看这四行：
-
GOROOT：应指向真实安装路径（如/usr/local/go或C:\Go），不能是空或$HOME/sdk/go1.26.0这类 Homebrew 管理路径（除非which go和它一致） -
GOPATH：Go 1.22+ 默认是$HOME/go，改过就要确认$GOPATH/bin真进了PATH；Windows 用户注意 PowerShell 写入的go env -w变量，CMD 可能读不到 -
GO111MODULE：必须为on；若为auto，执行go env -w GO111MODULE=on强制覆盖 -
GOPROXY：检查是否含direct（兜底直连），且第一个代理地址可连；用curl -I https://goproxy.cn验证 HTTP 状态码是否为 200
验证工具链是否真正打通
只跑通 go run main.go 是假阳性。必须验证命令安装和跨模块调用能力：
- 新建空目录，执行
go mod init testenv，确认生成go.mod - 写一个含
import "golang.org/x/net/html"的main.go，再跑go run main.go；若卡住或报module lookup failed，说明GOPROXY无效或网络不通 - 执行
go install golang.org/x/tools/cmd/gopls@latest，然后终端直接输gopls version；失败则要么$GOPATH/bin不在PATH，要么GOROOT指向错误（gopls启动时会读它）
工程模板验证：绕开 GOPATH 的最小闭环
Go 1.22+ 已彻底废弃 GOPATH/src 路径约束。正确流程是：
- 在任意路径（如
~/projects/myapi）建目录，cd 进去 - 执行
go mod init myapi—— 注意：模块名是逻辑标识，不是文件夹名，也不必带域名；写成github.com/you/myapi没错但没必要，私有项目用简单名更安全 - 写个
main.go，加一行import "net/http"，启动一个http.ListenAndServe服务 - 运行
go run .，curllocalhost:8080能返回内容，才算走通从初始化 → 编译 → 运行 → 依赖解析的全链路
这个闭环里最易被忽略的是：模块名和 import 路径必须一致，且所有依赖都由 go mod download 拉取进本地缓存，不依赖 GOPATH/src 下的手动软链或复制。一旦发现 go list -m all 输出里有 (replaced) 或 indirect 异常多，大概率是代理或缓存损坏，先 go clean -modcache 再重试。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
