Go Modules开启后GOPATH对依赖管理完全失效，仅影响go install二进制路径和旧版go get行为；判断模式需执行go env GO111MODULE（on/off/auto）和go list -m（成功返回模块名即module模式，报错则为GOPATH模式）。
Go Modules 开启后，GOPATH 对依赖管理完全失效，只影响 go install 的二进制落盘路径和旧版 go get 行为；所谓“冲突”，其实是误用模式导致的构建失败，不是两者真能共存打架。
怎么判断当前走的是 GOPATH 还是 Modules 模式
别猜，直接执行两条命令：
-
go env GO111MODULE：输出on表示强制模块模式；off表示彻底禁用（哪怕有go.mod也无视）；auto（Go 1.16+ 默认）表示“有go.mod就用 Modules，否则 fallback 到 GOPATH” -
go list -m：成功返回模块名说明已进入 module 模式；报错go: not in a module才是纯 GOPATH 模式
常见错误现象：go build 报 cannot find module providing package xxx，但你明明在 $GOPATH/src/xxx 下放了代码——这是因为 module 模式下根本不会扫描 $GOPATH/src，只认 replace、require 和本地 ./ 路径。
GO111MODULE=off 导致 CI 和本地行为不一致
这是协作中最隐蔽的坑：有人本地设了 GO111MODULE=off，go.sum 不生成、依赖版本不锁定，go mod tidy 也不生效，结果本地能跑、CI 构建失败或运行时 panic。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- CI 脚本里必须显式加
export GO111MODULE=on，不能依赖默认值 - 团队应统一要求提交
go.mod和go.sum，并禁止在 PR 中出现// indirect依赖未显式声明的情况 - 如果项目历史久远、还混着
vendor/目录，迁移前先删掉它再go mod init，否则go mod可能误读 vendor 内容，选错版本
历史项目迁移时 import 路径怎么改才不炸
GOPATH 时代习惯写 "utils" 或 "server/handler" 这类短路径，Modules 要求 import 必须匹配模块路径。但不是所有都要硬改：
- 本地子包如
./config、./internal/db保持点号路径即可，不用动 - 原跨项目引用（比如旧项目在
$GOPATH/src/github.com/user/repo），现在必须写成完整路径"github.com/user/repo/config" - 若用了
replace example.com/lib => ../lib，确保../lib目录下也有合法go.mod，否则go build会静默忽略 replace 并报错 - 用
grep -r 'import "' . --include="*.go" | grep -v '^\.' | grep -v '"/'快速扫出疑似短路径 import，再人工核对
GOPATH 还要不要设？设在哪？
要设，但用途只剩两个：
-
go install ./cmd/foo生成的可执行文件会落到$GOPATH/bin/foo，所以$GOPATH/bin必须在PATH里，否则装的工具（比如gopls）找不到 - 某些旧工具链（如部分 IDE 插件、CI 中的遗留脚本）仍会读
GOROOT和GOPATH，不设可能触发兼容性 fallback
建议保留 export GOPATH=$HOME/go，但明确知道它不再参与依赖解析——模块模式下，go list -m all 显示的版本与 $GOPATH 完全无关。
真正容易被忽略的点是：GO111MODULE=auto 在非模块目录下会自动 fallback，而这种 fallback 是静默的，不会报错，只会让你以为“依赖应该能找到”，结果编译失败。所以只要项目有 go.mod，就该把 GO111MODULE=on 写进 shell 配置或 CI 脚本，别信 auto。
