go mod download 对自定义域名模块没反应，是因为它只下载 go.mod 中显式 require 的远程模块；若模块被 replace 覆盖、未被 tidy 加入 go.mod、或 goproxy/gonoproxy 配置不当导致请求被错误转发，则不会触发下载。
go mod download 为什么对自定义域名模块没反应
因为 go mod download 默认只拉取 go.mod 中已声明的依赖，而自定义域名（比如 git.internal.company.com/mylib）若未被 require 显式写入、或被 replace 覆盖为本地路径，它根本不会进入下载列表。常见现象是：代码里 import "git.internal.company.com/mylib"，但 go mod download 什么也不输出，甚至 go list -m all 里都看不到它。
根本原因不是命令失效，而是 Go 模块解析器压根没把它当成“需要下载的远程模块”——它可能被 replace 成了本地路径，或者 go mod tidy 根本没把它加进 go.mod（比如 import 后没运行 tidy，或该包在构建时才被条件编译触发）。
- 先确认是否真被
require：打开go.mod，搜git.internal.company.com，看有没有对应行；没有就说明还没纳入模块管理 - 检查是否有
replace：如果有类似replace git.internal.company.com/mylib => ./internal/mylib，那go mod download就会跳过它（本地路径不需下载） - 运行
go mod tidy -v，观察是否报错如no required module provides package—— 这说明 Go 找不到该路径对应的模块定义，可能因私有仓库未配置认证或未暴露go.mod
GOPROXY 和 GONOPROXY 必须配对生效
自定义域名模块通常属于私有仓库，不能走公共代理，否则 go mod download 会卡住或报 404/401。但很多人只设了 GOPROXY，却忘了把私有域名加进 GONOPROXY，结果请求仍被转发到 goproxy.cn，自然失败。
正确做法是用逗号分隔多个域名，且必须精确匹配 import 路径前缀：
- 设置命令：
go env -w GONOPROXY="git.internal.company.com,dev.myorg.io" - 注意不要写成
https://git.internal.company.com或带通配符（*不支持），只写域名主体 - 如果子路径也属私有（如
git.internal.company.com/team/a和git.internal.company.com/team/b），只需写git.internal.company.com即可覆盖全部子路径 - 验证是否生效：
go env GONOPROXY输出应包含你的域名；再试go list -m git.internal.company.com/mylib@latest，看是否返回版本而非超时
离线场景下，自定义域名模块必须提前缓存完整版本
go mod download 在离线环境不会自动 fallback 到源码仓库或 SSH，它只查本地 $GOMODCACHE。而自定义域名模块往往使用 Git+SSH 或 HTTPS+Token 认证，一旦网络断开、密钥不可用或证书不被信任，go build 就会直接失败，哪怕代码里只 import 了一行。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
所以预下载必须确保两点：一是版本锁定（避免 @latest 动态解析），二是缓存中含完整模块元数据（包括 go.mod 文件）：
- 在有网机器上，先明确指定版本：
go get git.internal.company.com/mylib@v1.2.3（不是@latest） - 再运行
go mod download git.internal.company.com/mylib@v1.2.3，观察输出是否含go: downloading - 检查缓存目录：
ls $GOMODCACHE/git.internal.company.com/mylib@v1.2.3，确认里面有go.mod和cache/download/...下载记录 - 复制整个
$GOMODCACHE到离线机后，务必设GOPROXY=off和GOSUMDB=off，否则校验阶段仍会尝试连sum.golang.org
replace 到本地路径时，go mod download 完全不生效
如果你用 replace git.internal.company.com/mylib => ../mylib 把远程模块映射到本地目录，那 go mod download 就彻底绕过它——它只处理远程模块。此时依赖管理逻辑变了：Go 直接读取本地文件系统，不再走网络下载流程。
这本身没问题，但容易引发两个隐蔽问题：
- CI 构建失败：CI 环境里
../mylib路径不存在，go build报cannot find module - 版本不一致：本地
mylib目录里没go.mod，或go.mod版本号与主项目期望不符，go mod tidy可能误删replace行 - 解决方案：开发期可用
replace，但发布前应改回远程路径 + 固定版本，并用go mod download验证能否拉下来
真正麻烦的是混合模式：部分模块用 replace，部分走远程，而 go list -m all 输出里既看不到被 replace 的，也漏掉某些 indirect 依赖——这时光靠 go mod download 无法覆盖全部场景。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
