go模块依赖管理不依赖全局路径，真正需隔离的是项目级go.mod和构建上下文；gopath仅影响go install输出位置，gocache由uid自动隔离，手动设置反而引发路径错乱与工具链误判。
Go模块依赖管理本身不依赖全局路径，所谓“隔离全局路径”是个伪命题——真正要隔离的是项目级的go.mod和构建上下文，不是GOPATH或GOCACHE。
为什么不该动GOPATH或GOCACHE来“隔离依赖”
现代 Go（1.11+）默认启用 modules，GOPATH仅影响go install输出位置和旧式go get行为；GOCACHE是编译缓存，由 UID 自动隔离，不同用户互不干扰。手动设go env -w GOPATH=...不仅没用，反而会让go install把二进制写到错误目录，还可能触发工具链误判。
- 常见错误现象：
go install github.com/user/tool@latest后找不到命令——实际装到了你手动指定的GOPATH/bin，但该路径不在PATH里 - CI/CD 中更危险：多个 job 并发执行
go mod download，若共用GOCACHE（默认就是），完全没问题；但若强行改GOCACHE到临时目录，会丧失复用、拖慢构建 - 真正影响依赖解析的只有当前工作目录下的
go.mod，和GO111MODULE=on是否生效
go.work不是全局隔离，而是本地多模块协作开关
go.work只在你显式进入 workspace 目录并执行go命令时起作用，它不会改变单个模块的go.mod语义，也不影响 CI 构建或go build ./...行为。
- 使用场景：你在本地同时开发
api/、lib/、cli/三个子模块，想让它们互相引用最新代码而非发布版本 - 关键限制：
go.work文件必须放在顶层目录，且所有包含go.mod的子目录路径要显式列出；它不传播、不继承、不打包 - 容易踩的坑：把
go.work提交到 Git，但 CI 脚本仍用go build ./...——此时go.work被完全忽略，依赖仍按各子模块自己的go.mod解析
真正需要隔离的三件事，和怎么做
服务器上多项目共存，真正要防的是：A 项目升级依赖意外破坏 B 项目构建、旧版 Go 错误编译新版模块、敏感配置泄露。这些和“全局路径”无关，靠以下三点控制：
-
每个项目独立
go.mod+go.sum：绝不跨项目共享vendor/，也别把多个项目塞进同一GOPATH/src下——哪怕只是看着整洁，也会让go list -m all输出混乱 -
用
PATH顺序锁定 Go SDK 版本：比如 A 项目要求go 1.20，就确保其构建脚本开头执行export PATH="/opt/go-1.20/bin:$PATH"；B 项目用1.22，就换路径。别设GOROOT，新版 Go 能自动识别自身位置 -
运行时配置走
GO_ENV+ 显式校验：比如os.Getenv("DB_URL")前先检查os.Getenv("GO_ENV") == "production"，否则拒绝启动——这比任何路径隔离都更能防止配置错乱
复杂点在于：go.mod声明的go 1.22是硬约束，但服务器上可能同时装着 1.20 和 1.22；PATH 切错了，go version和go build用的就不是同一个二进制。这种错配不会报错，只会静默失败——比如errors.Is调用突然 undefined。
