GVM是Go多版本共存最稳的选择，通过独立安装各版本至~/.gvm/gos/并自动切换环境，避免GOROOT和PATH手动修改引发的CI/CD及多项目冲突问题。
gvm 是多版本共存最稳的选择
直接改 $GOROOT 和 $PATH 容易在 CI/CD 或多项目混用时出错，尤其当你同时维护一个依赖 go1.21.6 的微服务和一个要求 go1.22.3 的 CLI 工具时。gvm 专为 Go 设计，每个版本独立安装在 ~/.gvm/gos/ 下，切换不污染全局环境。
安装后务必检查是否生效：gvm list 应列出已安装版本；若提示 command not found: gvm，说明 ~/.gvm/scripts/gvm 没被 source，需在 ~/.zshrc 或 ~/.bashrc 末尾加两行：
source ~/.gvm/scripts/gvm export PATH="$HOME/.gvm/bin:$PATH"
重载配置后重启终端或执行 source ~/.zshrc。
按项目自动切换 Go 版本要靠 .gvmrc
全局执行 gvm use go1.22.3 只适合单项目终端会话，不适合混合开发场景。正确做法是进项目根目录后运行：
立即学习“go语言免费学习笔记（深入）”；
-
gvm use go1.21.6 --default→ 生成.gvmrc文件，内容为export GVM_GO_VERSION="go1.21.6" - 确保 shell 启用了 cd hook（gvm 安装时默认开启），否则进入目录不会自动加载
- 验证：执行
go version和echo $GOROOT，前者应输出匹配版本，后者应指向~/.gvm/gos/go1.21.6
注意：如果项目 go.mod 中声明了 go 1.22，而你硬切到 go1.21.6，go build 会直接报错 go: cannot use go 1.21.6 with go 1.22 mod —— 这不是 gvm 的问题，是 Go 工具链的强制校验。
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
交叉编译必须显式传 GOOS/GOARCH，Makefile 里不能 export
Makefile 不继承 shell 环境变量，export GOOS=linux 对下一行 go build 完全无效。所有构建命令必须前置变量：
- 正确写法：
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o bin/app-linux-amd64 ./cmd/main - Windows 必须加
.exe后缀：-o bin/app-windows-amd64.exe，否则生成的文件无扩展名，CI 流水线可能误判为非可执行文件 - ARM 架构需额外指定：
GOARCH=arm64或GOARCH=386 GOARM=7（ARMv7）；GOAMD64=v3用于启用 AVX 指令集（如 Intel 第11代+ CPU） - 每次构建前加
mkdir -p bin/，避免因目录不存在导致go build失败
输出路径建议带平台标识，例如 app-$(GOOS)-$(GOARCH)，否则反复 make 会覆盖旧二进制，发包时极易拿错。
CGO_ENABLED=0 不是可选项，是跨平台静态编译的前提
默认开启 CGO 会导致 Linux 二进制依赖 libc，在 Alpine 容器中运行会报 not found；macOS 编译 Windows 二进制则直接失败。所以只要做交叉编译，一律加前缀 CGO_ENABLED=0。
副作用要注意：
- 禁用 CGO 后，
net包默认使用纯 Go DNS 解析器（netgo），不读取/etc/resolv.conf，若项目依赖系统 DNS 配置（比如某些内网解析规则），需要显式设置GODEBUG=netdns=go或改用cgo模式 -
os/user、os/exec等包行为基本不变，但涉及系统调用的第三方库（如某些 SQLite 驱动）可能失效
真正容易被忽略的是：即使你只在本地 macOS 开发，只要 Makefile 里有跨平台构建目标，就必须每条命令都加 CGO_ENABLED=0 —— 少一次，就可能在某次 CI 构建中悄悄引入动态链接，上线后才暴露。
