go环境包管理核心是模式混用：go111module开关、go.mod存在与否、gopath设置不一致导致构建失败；判断模式需用go list -m（成功输出模块名即module模式，报错“not in a module”即gopath模式）和go env go111module（on为强制module，off为禁用module，auto为有go.mod则启用）；modules模式下依赖只认go.mod require、replace及本地相对路径，完全不扫描$gopath/src。
Go 环境搭建中包管理问题的核心，不是“装没装好”，而是“模式混用”——GO111MODULE开关、go.mod存在与否、GOPATH路径设置三者不一致，直接导致go build报cannot find package或cannot find module providing package。
怎么判断当前项目走的是 GOPATH 还是 Modules 模式
别猜，用命令验证：
- 运行
go list -m：成功输出模块名（如example.com/myproj）→ 已进入 module 模式；报错go: not in a module→ GOPATH 模式 - 运行
go env GO111MODULE：输出on表示强制启用 modules；off表示彻底禁用（哪怕有go.mod也无视）；auto（Go 1.16+ 默认）表示“有go.mod就用 modules，否则 fallback 到 GOPATH” - 检查项目根目录：有没有
go.mod文件？有且GO111MODULE=on或auto→ 必走 modules；没有 +GO111MODULE=off→ 只认$GOPATH/src
go build 报 cannot find module providing package xxx 的真实原因
这不是网络问题，也不是代理没设对，而是 modules 模式下依赖查找路径被严格收窄：
- modules 模式完全不扫描
$GOPATH/src，哪怕你手动把github.com/user/pkg放进去了，go build也视而不见 - 它只认三处：①
go.mod中require声明的远程模块；②replace指向的本地路径（必须是相对路径，如./local-pkg）；③ 当前项目内用./subdir这种相对导入的子包 - 常见错误场景：你在
$GOPATH/src/github.com/xxx/lib改了代码，但没在go.mod里加replace github.com/xxx/lib => ./lib→ modules 直接跳过，报找不到 - 临时验证：删掉项目里的
go.mod，再跑go build—— 如果突然能过了，说明你之前是误入 modules 模式，而代码结构其实是按 GOPATH 组织的
GO111MODULE=off 导致 CI 和本地行为不一致
这是协作中最隐蔽的坑：有人本地 export GO111MODULE=off，go get 直接往 $GOPATH/src 写，go.sum 不生成，go mod tidy 失效。结果是：
- 本地能跑，CI 因为默认
on而失败 -
go.mod里缺require条目，别人 clone 后go build直接报错 - 依赖版本没锁定，下次
go get可能拉到破坏性更新 - 解决方案：统一在项目根目录放一个
.envrc（如果用 direnv）或 CI 脚本开头强制写死：export GO111MODULE=on；新项目初始化后立刻执行go mod tidy并提交go.mod和go.sum
国内拉不到 golang.org/x/ 等模块怎么办
这不是 Go 的 bug，是网络策略导致的 HTTP 请求超时，解决方式非常明确：
- 设代理：运行
go env -w GOPROXY=https://goproxy.cn,direct（七牛云）或https://mirrors.aliyun.com/goproxy/（阿里云） -
direct是关键：它表示对私有域名（如公司内部git.company.com）跳过代理，避免内网模块被转发出去 - 若需跳过更多私有域名，追加
go env -w GOPRIVATE=git.company.com,github.company.internal - 注意：代理只影响
go get和go mod download，不影响go build时的依赖解析逻辑 —— 解析仍只看go.mod，下载才走代理
最常被忽略的一点：Modules 模式下 GOPATH 并未消失，它只管两件事——go install 生成的二进制往哪放（$GOPATH/bin），以及 go get 在无模块时的老行为。其余所有依赖管理、构建、版本锁定，都和 GOPATH 无关。混淆这点，是绝大多数“环境配置失败”的根源。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
