先确认Go二进制是否真正在PATH里，再检查which go路径与GOROOT是否一致；go mod init失败需确保GO111MODULE=on且当前目录无GOPATH/src约束；gopls报错应打开含go.mod的根目录并配置GOPROXY；go install替代go get且必须加@latest后缀。
go version命令报错或输出异常
先确认Go二进制是否真正在PATH里，而不是“看起来装了”。常见现象是go version报command not found或输出go version devel go1.27-这类非正式版本——说明你可能混用了多个安装源（比如MSI安装+手动解压+go install golang.org/dl/go1.26@latest）。
检查步骤：
• 运行which go（macOS/Linux）或where go（Windows），看路径是否指向预期位置（如/usr/local/go/bin/go或C:\Go\bin\go.exe）
• 执行echo $GOROOT（macOS/Linux）或echo %GOROOT%（Windows），确保它不为空且与which go的父目录一致
• 若GOROOT指向/usr/local/go但which go返回/home/xxx/go/bin/go，说明环境变量冲突，删掉冗余的GOBIN或PATH追加项
go mod init失败：cannot find package "." in: ...
这不是Go没装好，而是当前目录没在模块感知范围内。最常见原因是：你在$GOPATH/src下却没用go mod init初始化，或在模块项目里误设GO111MODULE=off。
快速验证：
• 运行go env GO111MODULE，输出应为on（Go 1.16+默认）
• 检查当前目录是否有go.mod文件；没有就执行go mod init example.com/myapp（随便起个模块名）
• 如果目录在$GOPATH/src里且无go.mod，Go会尝试按旧GOPATH规则找包，但找不到.——直接删掉$GOPATH/src路径约束，用模块模式重来
• 注意：VS Code里终端可能继承了错误的shell配置，新开一个纯终端再试
gopls或Go插件报错：no module found / failed to load workspace
VS Code的Go扩展依赖gopls读取go.mod构建项目视图。报错通常意味着工作区根目录没识别到有效模块。
实操要点：
• 确保VS Code打开的是**包含go.mod的文件夹**，不是其子目录或父目录
• 在项目根目录运行go mod download，确认依赖能拉下来；若卡住，检查go env GOPROXY是否设为https://goproxy.cn,direct（国内必需）
• 删除go.sum和vendor/（如有），再跑go mod tidy重建依赖快照
• 不要同时打开多个含go.mod的文件夹作为workspace，gopls会混淆
go get或go install第三方工具失败
从Go 1.18起，go get不再向$GOPATH/bin写入可执行文件，必须用go install <path>@latest。旧教程里go get golang.org/x/tools/cmd/godoc已失效。
典型错误：
• can't load package: package golang.org/x/tools/cmd/godoc is not a main package → 忘了加@latest后缀
• module github.com/swaggo/swag@latest found, but does not contain package github.com/swaggo/swag/cmd/swag → 路径写错，正确是github.com/swaggo/swag/cmd/swag@latest
• 安装后swag命令仍不可用 → 检查$GOBIN是否在PATH里，或直接用$GOBIN/swag调用
立即学习“go语言免费学习笔记（深入）”；
环境变量和模块模式的交叉影响最容易被忽略，尤其当你在不同项目间切换时，GO111MODULE状态、GOPROXY值、甚至终端启动方式（GUI点击 vs shell中启动）都可能导致同一命令行为不一致。 
