Nexus 能托管大型团队的 Go 模块依赖，但必须同时配齐 go (proxy)、go (hosted) 和 go (group) 三类仓库，且 GOPROXY 必须指向 go (group) 的 URL（末尾斜杠不可省），否则模块拉取会随机失败或降级回公网。
直接说结论：Nexus 能托管大型团队的 Go 模块依赖，但必须同时配齐 go (proxy)、go (hosted) 和 go (group) 三类仓库，且 GOPROXY 必须指向 go (group) 的 URL（末尾斜杠不可省），否则模块拉取会随机失败或降级回公网。
为什么不能只用 go (proxy) 或只建 go (group)？
很多人以为建个 go (proxy) 就能缓存所有公共模块，再加个 go (group) 合并一下就完事——这是最典型的配置陷阱。实际中：
-
go (proxy)只负责代理和缓存golang.org/x、github.com等公开模块，不存私有模块，也不响应@v/list这类 discovery 请求（除非 Remote storage 明确设为https://proxy.golang.org/） -
go (group)本身不存储任何内容，它只是个聚合入口；如果里面没加go (hosted)，私有模块（如gitlab.corp/internal/pkg）根本不会被识别 - 只建
go (hosted)而不配go (proxy)，会导致所有公共模块都得走 VCS（git clone），既慢又易受网络波动影响
GOPROXY 地址必须带末尾斜杠，且不能含路径参数
Go 客户端拼接请求路径时是硬编码逻辑：GOPROXY + /github.com/org/repo/@v/v1.2.3.info。如果地址写成 https://nexus.example.com/repository/goproxy（缺 /），就会变成 .../goproxygithub.com/...，404。
- 正确格式：
https://nexus.example.com/repository/goproxy/（注意结尾/） - 错误示例：
https://nexus.example.com/repository/goproxy、https://nexus.example.com/repository/goproxy/v1、http://（Go 1.13+ 默认拒绝 HTTP，除非加,direct并设GONOSUMDB） - 验证方式：手动
curl -I https://nexus.example.com/repository/goproxy/github.com%2Fgorilla%2Fmux/@v/list，返回 200 + text/plain 才算通
私有模块必须靠 GOPRIVATE + hosted 仓库双配合
Go 默认对匹配 GOPRIVATE 的域名跳过 GOPROXY，直接走 VCS。想让它也走 Nexus，就得让 Nexus “假装自己是那个 VCS”——这只能靠 go (hosted) 仓库实现。
立即学习“go语言免费学习笔记（深入）”；
- 客户端设
GOPRIVATE=gitlab.corp/*（不是gitlab.corp，必须带/*） - Nexus 里建
go (hosted)仓库（比如叫go-internal），并确保其 Repository Path 是/repository/go-internal/ - 把
go-internal加进go (group)，再把 group 的 URL 设为GOPROXY - 首次发布私有模块：在模块根目录执行
go mod publish -v v1.0.0（需 Nexus 开启Allow redeploy），或用curl -X PUT手动上传.mod和.zip
大型团队要防缓存污染和校验失效
多人共用一个 go (proxy) 时，go.sum 校验失败不是小概率事件。Nexus 默认不做 go.sum 验证，但客户端校验失败后不会自动重试，而是报 invalid version: unknown revision。
- 关键动作：在
go (proxy)仓库设置里关掉Strict Content Validation（否则 Nexus 会拦截非标准响应） - 建议开启
Metadata Max Age（如 1440 分钟）和Component Max Age（如 10080 分钟），避免缓存陈旧模块 - 若团队使用 GitLab CI，应在
.gitlab-ci.yml中显式设GOPROXY和GOPRIVATE，防止 CI 环境读错本地 env - 不要依赖 Nexus 自动解析
go.sum；校验失败时优先检查go (hosted)是否漏传了.zip文件（.mod有但.zip缺失是常见原因）
真正卡住大型团队的，往往不是仓库建不起来，而是 go (group) 里漏加 go (hosted)、GOPROXY 少了个斜杠、或者私有模块没走 go mod publish 就直接 go get ——这些地方一错，整个依赖链就静默降级，排查起来极耗时间。
