Go mod拒绝HTTP源是因为Go 1.13+默认启用模块验证和安全传输，强制要求TLS加密通道以防止中间人攻击；必须同时设置GOPROXY=direct和GONOSUMDB覆盖对应域名，否则校验失败。
为什么go mod会拒绝HTTP源而报错
Go 1.13+ 默认启用模块验证和安全传输，go mod 遇到 http://（非 TLS）协议的模块源时直接拒绝，报错类似 invalid version: git ls-remote origin in ... failed: fatal: unable to access 'http://git.example.com/repo.git/': Protocol "http" not supported or disabled in libcurl 或更常见的 verifying github.com/user/pkg@v1.2.3: github.com/user/pkg@v1.2.3: reading https://sum.golang.org/lookup/github.com/user/pkg@v1.2.3: 410 Gone ——本质是 Go 拒绝降级到不加密通道，防止中间人篡改依赖。
GONOSUMDB 和 GOPROXY=direct 必须配对使用
仅设 GOPROXY=direct 不够：Go 仍会尝试向 sum.golang.org 校验 checksum，而私有 HTTP 源没提供签名或校验服务，导致校验失败。必须同时关闭校验：
-
go env -w GONOSUMDB="git.example.com,github.com/my-org/*"（逗号分隔，支持通配符） -
go env -w GOPROXY=direct（跳过代理，直连 HTTP 源） - 若需保留部分公库走代理，可用多级
GOPROXY，但GONOSUMDB范围必须覆盖所有 HTTP 源域名
内网 Git 仓库拉取失败的典型配置组合
假设你用的是内网自建 GitLab，地址为 http://gitlab.internal/project/repo，且无 HTTPS：
- 确认
go.mod中 replace 或 require 的路径与实际仓库 URL 完全一致（包括http://前缀） - 执行：
go env -w GOPRIVATE="gitlab.internal"（让 Go 不走代理，但还不够） - 必须追加：
go env -w GONOSUMDB="gitlab.internal"（否则 sum.golang.org 校验失败） - 再运行
go mod download -v，观察是否从http://gitlab.internal直连并跳过 checksum 校验
漏掉 GONOSUMDB 是最常见坑——很多人只设 GOPROXY=direct 或 GOPRIVATE，结果卡在 verifying ...: checksum mismatch 或空响应。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
临时调试：用 curl 模拟 Go 的 fetch 行为
Go 拉取模块本质是走 Git 协议或 HTTP GET /@v/list、/@v/v1.2.3.info 等端点。快速验证是否真能通：
-
curl -v http://gitlab.internal/project/repo/@v/list（应返回版本列表文本） -
curl -v http://gitlab.internal/project/repo/@v/v1.2.3.info（应返回 JSON 元信息） - 若返回 404，说明仓库未启用 Go module 支持（如 GitLab 需开启
go modules功能或用go mod publish工具注入元数据） - 若 curl 成功但
go mod失败，大概率是GONOSUMDB未生效或域名拼写不一致（注意大小写、子域、端口）
真正麻烦的不是配环境变量，而是 HTTP 源本身没暴露 Go module 所需的元数据端点——这时 proxy 或 direct 都无效，得先补上服务端支持。
