答案是执行go env GO111MODULE和go list -m：前者输出on/off/auto判断模式开关，后者成功返回模块名即module模式、报错“not in a module”即GOPATH模式。
核心问题不是环境“不一致”，而是部分机器在 GOPATH 模式下运行，而另一些在 Modules 模式下运行——GO111MODULE 的实际值不同，直接导致 go build、go get、go mod tidy 行为完全割裂。
怎么一眼判断本地走的是 GOPATH 还是 Modules 模式
别看 IDE 状态栏或猜项目有没有 go.mod，执行这两条命令最可靠：
-
go env GO111MODULE：输出on表示强制模块模式；off表示彻底禁用（哪怕有go.mod也无视）；auto（Go 1.16+ 默认）表示“有go.mod就用 Modules，否则 fallback 到 GOPATH” -
go list -m：成功返回模块名（如example.com/myapp）说明已进入 module 模式；报错go: not in a module才是纯 GOPATH 模式
常见错误现象：go build 报 cannot find module providing package xxx，但你明明把代码放在 $GOPATH/src/xxx 下——这是因为 module 模式下根本不会扫描 $GOPATH/src，只认 replace、require 和本地 ./ 路径。
CI/CD 构建失败的隐蔽根源：GO111MODULE=off
这是协作中最容易被忽略的坑：有人本地设了 GO111MODULE=off，go.sum 不生成、依赖版本不锁定、go mod tidy 不生效，结果本地能跑、CI 构建失败或运行时 panic。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- CI 脚本里必须显式加
export GO111MODULE=on，不能依赖默认值 - 团队应统一要求提交
go.mod和go.sum，并禁止在 PR 中出现// indirect依赖未显式声明的情况 - 如果项目历史久远、还混着
vendor/目录，迁移前先删掉它再go mod init，否则go mod可能误读vendor内容，选错版本
跨平台开发时 GOPROXY 和 GOPRIVATE 必须显式配置
Windows、Linux、macOS 的 shell 加载机制不同，VS Code Remote-Containers 或 Docker 构建中，GOPROXY 很容易被覆盖或未加载，导致拉包失败或走错代理。
- 私有仓库场景下，
GOPRIVATE=git.example.com/*必须设置，否则 Go 仍尝试走proxy.golang.org，导致 403 或超时 - 内网环境可配
GOPROXY=https://goproxy.cn,direct（注意,direct不能少，否则私有库无法 fallback） - 远程开发容器中，需在
.devcontainer/devcontainer.json显式透传："remoteEnv": { "GOPROXY": "https://goproxy.cn,direct", "GOSUMDB": "sum.golang.google.cn" }
Docker 构建中环境不可控的典型表现
镜像标签用 :latest 或 :1.21，某天基础镜像升级后，go version 实际变了，GO111MODULE 默认行为或 MVS 策略微调，导致构建产物不一致。
- 固定镜像标签：
FROM golang:1.21.5-bullseye（而非:1.21或:latest） -
WORKDIR和COPY顺序要严格：先COPY go.mod go.sum .，再RUN go mod download，利用 Docker 层缓存且隔离依赖状态 - 避免
RUN go get -d -v ./：该命令忽略go.sum校验，且 Go 1.21+ 已弃用go get用于依赖管理
真正难的不是“配一次”，而是让每次 go build、每个 dlv 调试会话、每台 CI 机器上的 go list -m all 都看到完全相同的 GOROOT、GOPATH 和模块代理行为——这要求所有配置必须可复现、不可覆盖、不依赖交互式 shell 加载时机。
