go 1.11+ 迁移核心是确保模块感知正确：先验证 gopath/goroot 和标准库完整性，再清理残留文件、用规范域名初始化 go.mod，修正 import 路径，并通过 go mod tidy 修复依赖。
Go 1.11 之后，go mod 已成为默认依赖管理方式，GOPATH 不再是硬性要求；但忽略它仍会导致 go get 失败、IDE 无法识别包、go run 报错“no Go files in current directory”等实际问题。
验证 go 是否真正可用，不只是看 go version
只运行 go version 成功 ≠ 环境就 ready。真正要检查的是三件事：
-
go env GOPATH输出是否非空（即使不用传统 GOPATH 模式，很多工具如gopls仍会 fallback 到它） -
go env GOROOT是否指向真实安装路径（尤其 Windows 用户常因多版本共存导致混乱） -
go list std | head -n 3能否列出标准库（验证GOROOT下的src和pkg完整）
如果 go list std 报错或卡住，大概率是 GOROOT 损坏或权限异常，不要强行继续配置 IDE。
go mod init 前必须确保当前目录可写且无残留 go.sum
新建项目时，很多人直接 mkdir myapp && cd myapp && go mod init myapp，但若该目录曾被其他 Go 工具（如旧版 dep 或误操作的 go build）写入过 go.sum 或 vendor/，go mod init 会静默失败或生成错误 module path。
- 执行前先清理：
rm -f go.sum go.mod vendor/ - module name 不要写成
myapp这类裸名——它会被解析为相对路径，后续import时可能触发 “unknown import path” 错误；应使用域名格式，如example.com/myapp或至少github.com/yourname/myapp - 若项目在
$HOME/go/src下，go mod init会自动推导 module path，但不推荐依赖此行为——它和GOPATH强耦合，易在 CI 或多用户环境出问题
VS Code 中 gopls 启动失败，90% 是代理或缓存问题
VS Code 安装 Go 插件后首次打开 .go 文件，会自动下载 gopls（Go Language Server）。国内用户常见现象：状态栏一直显示 “Installing tools…”，或弹窗报错 failed to install gopls: could not determine module path。
- 先手动设置代理：
go env -w GOPROXY=https://goproxy.cn,direct（注意不是https://proxy.golang.org） - 再清除模块缓存：
go clean -modcache - 重启 VS Code，**不要**点插件弹窗里的 “Install All” —— 改用命令面板（
Ctrl+Shift+P）运行Go: Install/Update Tools，勾选gopls单独安装
如果仍失败，检查 ~/.bashrc 或 ~/.zshrc 是否有重复的 export GOPROXY=... 导致冲突——go env 显示的值才是最终生效的。
go run 报错 “cannot find package” 时，先看 go list -m all
这个错误表面是找不到包，根源往往是模块感知错乱。比如你 import "github.com/gin-gonic/gin"，但 go run 提示找不到，不要急着 go get。
- 运行
go list -m all—— 如果输出为空或只有your-module-name，说明模块未正确初始化或go.mod被删了 - 如果输出里有
github.com/gin-gonic/gin v1.9.1但依然报错，执行go mod verify检查校验和是否损坏 - 最稳妥的修复方式：
go mod tidy（它会重新拉取依赖并修正go.mod和go.sum），而不是单独go get某个包
真正容易被忽略的点是：go run 默认只运行当前目录下的 *.go 文件，如果你把 main.go 放在子目录（如 cmd/server/main.go），必须显式写成 go run cmd/server/main.go，否则它根本不会扫描子目录。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
