Go多版本共存完全可行，关键在隔离安装路径与精确控制PATH：Windows用批处理切换PATH，Linux/macOS用软链接+别名，无需GOROOT或gvm；go.mod中的go指令仅声明最低兼容版本，不影响高版本构建。
Go 多版本共存完全可行，关键不在装几个 Go，而在 PATH 是否干净、GOROOT 是否被误设、go.mod 中的 go 指令是否与实际运行版本冲突。
如何避免 GOROOT 干扰多版本切换
新版 Go（1.17+）已不再依赖全局 GOROOT：它能自动识别自身安装路径。一旦你手动设置了 GOROOT，反而会卡死切换逻辑——比如 gvm use 或软链接切换后，go version 显示正确，但 go build 仍用旧版本编译器。
- Linux/macOS：彻底删除
export GOROOT=...行，只靠PATH控制生效版本 - Windows：不要在系统环境变量里设
GOROOT，批处理脚本也只改PATH，不碰GOROOT - 验证方式：执行
go env GOROOT，输出应为当前go二进制所在目录（如/home/user/.gvm/gos/go1.22.3），而非你手动指定的路径
go.mod 中的 go 指令不是建议，是硬性约束
当你在项目根目录执行 go build 时，Go 工具链会检查 go.mod 第一行的 go 1.22，然后比对当前 go 命令版本。若低于该值（如用 go1.21.6 构建声明 go 1.22 的模块），会直接报错：go: cannot use go 1.21.6 with go 1.22 mod。
- 这个检查发生在构建早期，不依赖 GOPATH 或 vendor，也无法绕过
- CI 脚本中必须显式确保
go version≥go.mod声明值，否则构建失败 - 本地开发时，
gvm use或g use后务必用go version确认，别只信终端提示
条件编译不是“写 if 判断 OS”，而是靠文件名和 build tag
Go 的条件编译机制不支持运行时判断，只在编译期生效。它靠两种方式过滤源文件：_linux.go 这类后缀，或 //go:build linux 这类 build tag。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 文件名规则优先级更高：一个
server_linux.go文件，即使内容里写了//go:build windows，也会被 Linux 下的go build加载 - build tag 必须写在文件顶部紧邻 package 声明前，且中间不能有空行；常用写法：
//go:build linux || darwin，注意用||不是or - 交叉编译时，
GOOS=linux go build会自动匹配_linux.go和//go:build linux文件，无需额外参数 - 调试时想强制包含某文件，可用
go build -tags=debug，前提是该文件顶部有//go:build debug
VS Code 中 gopls 识别错误，大概率是工作区没对齐模块根目录
VS Code 的 gopls 默认以打开的文件夹为工作区根，但它真正需要的是模块根目录（含 go.mod 的那个目录）。如果打开的是父级 monorepo 目录，gopls 可能无法解析 replace 或本地 require 路径，导致跳转失败、类型提示为空。
- 解决方法：在 VS Code 中右键点击含
go.mod的子目录 → “Reopen Folder in New Window” - 不要依赖 “Auto-detect GOROOT”：Settings > Go > GOROOT 必须手动指向当前项目所用 Go 版本的安装路径（如
~/.gvm/gos/go1.22.3） - 如果用了
go work，确保工作区是go.work所在目录，且gopls已加载 workspace mode
最易被忽略的点：go install 总是把二进制放到 $GOBIN（默认 $GOPATH/bin），但这个路径和你当前用的 Go 版本无关——它只取决于环境变量。所以不同 Go 版本下 go install 的工具可能互相覆盖，建议统一设 GOBIN=$HOME/.local/bin 并加入 PATH。
