迁移后验证需同时执行go version和which go（或where go），确保二者路径一致并指向预期版本安装目录，否则PATH未更新或软链接未重建，将导致IDE、CI及模块解析异常。
迁移后多版本共存不是“装完就完”，而是要确保新环境里每个项目启动时自动加载匹配的 Go 二进制，且不干扰 IDE、CI 和模块解析逻辑。核心矛盾在 PATH、GOROOT、go.mod 声明三者是否对齐——错一个，go build 就可能静默用错版本，gopls 就会报 no module found。
迁移后验证 go version 和 which go 是否一致
这是最常被跳过的一步。很多人只运行 go version 看到 “1.22.3” 就以为切换成功，但没确认实际调用的是哪个二进制。
- 必须同时执行：
go version和which go（macOS/Linux）或where go（Windows） - 输出路径应指向你期望的版本安装目录，例如
~/.g/go_versions/1.22.3/bin/go或C:\go1.22.3\bin\go.exe - 若
which go指向旧路径（如/usr/local/go/bin/go），说明 PATH 未更新，或软链接未重建 - Windows 上用
setx PATH修改后，新 CMD 才生效；旧窗口仍用旧 PATH，需重启终端
IDE（VS Code / GoLand）不识别新版本的典型原因
编辑器不会主动 reload PATH 变更，尤其当它已在后台运行时。gopls 启动后会缓存 GOPATH/GOROOT，改了环境变量也不自动刷新。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- VS Code：必须关闭所有窗口，再重新用
code .从命令行打开项目根目录（不是仓库顶层） - GoLand：右键点击含
go.mod或go.work的目录 → “Mark Directory as → Go Module Root” - 两者都需检查设置中是否启用了
go.toolsEnvVars，例如：{"GOFLAGS": "-mod=mod"}，否则可能绕过当前模块约束 - 验证方式：命令面板执行 “Go: Toggle Logs”，看 gopls 启动日志里的工作目录是否等于
go.mod所在路径
go.mod 的 go 指令被悄悄升级怎么办
迁移后首次运行 go mod tidy 或 go get，Go 工具链可能把 go 1.21 自动改成 go 1.26——这不是 bug，是 Go 官方行为，但会直接导致 CI 构建失败。
- 立即检查：
grep '^go ' go.mod，确认是否被修改 - 强制锁回原版本：
go mod edit -go=1.21（即使你在 1.26 环境下运行，也会写死该值） - CI 脚本中不能依赖本地环境，必须显式声明版本，例如 GitHub Actions：
uses: actions/setup-go@v5+with: { go-version: '1.21' } - 注意：
go version输出的是工具链版本，go.mod里的go行才是编译兼容性契约——两者可以不同，但必须满足“工具链 ≥ 契约版本”
.go-version 或 .tool-versions 文件没生效？检查加载钩子
这类文件本身只是静态声明，需要 shell 或 IDE 主动读取。没有钩子，它就是个普通文本。
- g 工具用户：确认
~/.zshrc或~/.bashrc中已加载官方提供的三行函数（见g文档），否则g use不会自动读.go-version - asdf 用户：确认已执行
asdf plugin add golang，且 shell 启动时加载了asdf.sh；.tool-versions必须放在项目根目录，不能嵌套在子目录 - Windows 用户：批处理脚本或
setx不读这些文件，必须手动切换或集成到构建脚本（如 Makefile 中先调set PATH=C:\go1.21\bin;%PATH%） - 最易忽略的一点：VS Code 的 Remote-SSH 或 WSL 连接下，shell 配置文件可能不是
~/.zshrc，而是~/.bash_profile或/etc/profile，钩子要加对地方
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
