Go模块跨子网同步失败的根本原因是工具链在DNS解析、代理路由或认证环节中断，需用go mod download -v -x定位真实请求，再手动执行curl验证是DNS、连接还是TLS问题。
Go 模块依赖跨越多个子网时的同步失败，根本不是网络“跨子网”本身的问题，而是 Go 工具链在解析模块路径、拉取代码、校验 checksum 时，无法按预期访问目标源——通常卡在 DNS 解析、代理路由或权限认证环节。直接配 GOPROXY 或改 replace 很少能根治，得先确认请求实际发往了哪里。
go mod download 卡在 dial 或 timeout，怎么快速定位是哪一环断了
这不是代码问题，是 Go CLI 在底层 net.Dial 阶段阻塞，且不响应 Ctrl+C。盲目重试或换镜像可能掩盖真实故障点。
- 加
-v和-x看真实请求：go mod download -v -x github.com/org/repo@v1.2.0，最后一行会输出类似curl -sSL https://proxy.golang.org/github.com/org/repo/@v/v1.2.0.info的命令 - 手动执行那条
curl命令，观察是 DNS 失败（Could not resolve host）、连接超时（Connection timed out），还是 TLS 握手失败（SSL connect error） - 若 curl 成功但
go mod download失败，大概率是 Go 自带 DNS 解析器（netdns=go）在特定子网下异常；可临时用go env -w GODEBUG=netdns=cgo切换到系统 DNS
私有模块路径被 proxy 中间件劫持，导致 404 或 403
当模块路径形如 git.company.internal/group/lib，而 GOPROXY 设为 https://goproxy.cn,direct 时，“,direct”仅对未匹配 GONOPROXY 的域名生效。如果没配 GONOPROXY，Go 仍会尝试把私有路径发给 goproxy.cn，结果当然是 404。
- 必须显式配置
GONOPROXY：例如go env -w GONOPROXY="git.company.internal,10.0.0.0/8" - 若公司用自建 Athens 代理，且它支持私有模块，则
GOPROXY应设为https://athens.company.internal,direct，同时确保GONOPROXY不包含该域名 -
GOPRIVATE和GONOPROXY功能不同：GOPRIVATE控制是否跳过 checksum 校验，GONOPROXY控制是否绕过 proxy 直连——两者常需同时设置
replace 指向本地路径后，CI 构建失败且报 unknown revision
replace 是开发期临时方案，只在当前模块生效，且完全绕过远程解析。CI 环境没你本地的 ./lib 目录，自然找不到 revision。
立即学习“go语言免费学习笔记（深入）”；
- CI 脚本中必须清理
replace：运行go mod edit -dropreplace=github.com/org/lib，或用go mod edit -replace=github.com/org/lib=github.com/org/lib@v1.2.0还原为标准引用 - 更稳妥的做法是：开发分支保留
replace，发布前通过 CI 流水线自动 checkout 干净的 tag，并用GOFLAGS="-mod=readonly"启动构建，提前暴露 replace 未清理问题 - 不要依赖
go mod tidy自动修复——它不会删replace，也不会警告你该删
真正难处理的，是那些看似通了、但 go list -m all 显示的模块路径和你预期不一致的情况。比如显示 github.com/org/lib => ./lib，但 ./lib 下的 go.mod 里写的却是 module gitlab.company.internal/org/lib——这种 mismatch 会导致下游模块 import 失败，且错误信息极其隐蔽。
