根本原因是go mod download等操作默认无超时，DNS/TCP/代理任一环节阻塞即无限等待；必须设GOPROXY=https://goproxy.cn,direct、同步配GONOPROXY和GOSUMDB，并用go mod download -x定位卡点。
多平台构建（如 GOOS=linux GOARCH=arm64 go build）本身不触发网络，但构建过程中依赖的 go mod download、go get 或 go run 执行远程 fetch 时会卡死——根本原因不是“构建超时”，而是模块拉取阶段未设超时，DNS/TCP/代理链路任一环节阻塞就无限等待。
go mod download 超时必须靠环境变量 + 自定义 GOPROXY
Go 的模块下载器（go mod download）默认不读 http.Client.Timeout，也不响应 context.WithTimeout，唯一可控入口是环境变量和代理配置：
-
GOPROXY必须显式设置（如https://proxy.golang.org,direct），避免 fallback 到直连私有仓库或不可靠镜像导致 DNS 解析卡住 -
GONOPROXY和GOSUMDB要同步调整，否则sum.golang.org校验失败会重试 10+ 次且无超时 - 无法通过代码控制，但可在 CI 脚本中加兜底：
timeout 30s go mod download || echo "mod download timeout, retrying with -x" - 调试时加
-x参数看卡在哪一步：go mod download -x会输出每条 HTTP 请求，定位是 DNS、CONNECT 还是 TLS 握手失败
CI 环境下 go build 触发隐式网络请求的场景
看似纯本地的 go build 可能在以下情况偷偷发起网络请求，且默认无超时：
- 使用了
//go:embed引用远程 URL（极少见，但 Go 1.22+ 支持） - 构建时执行了
go:generate脚本，而脚本里调用了curl、wget或go run下载工具 - 自定义
build tags导致条件编译引入了含http.Get的 init 函数（例如某些 SDK 的自动上报逻辑） -
go install安装命令行工具（如gofumpt）时触发go get，尤其在Makefile中未锁定版本易反复拉取
这类问题不会报错，只会让 CI job 卡在 “running” 状态数分钟，pprof 显示 goroutine 停在 net.(*pollDesc).wait。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
交叉编译容器内 DNS 和连接超时的真实控制点
在 golang:1.23-alpine 等镜像中构建多平台二进制时，/etc/resolv.conf 配置不当会导致 DNS 查询无限重试（Linux 默认 5 次，每次 5 秒 → 最长 25 秒）。这不是 Go 控制的，但直接影响 go mod download：
- 启动容器时强制指定 DNS：
docker run --dns=8.8.8.8 --dns=1.1.1.1 ... - 禁用 IPv6（Alpine 默认启用）：在构建前加
sysctl -w net.ipv6.conf.all.disable_ipv6=1，避免 AAAA 查询拖慢 -
net.Dialer.Timeout对go mod无效，但对构建后运行时的 HTTP 客户端有效——别混淆这两个阶段 - 若必须用私有 proxy，确保其
ResponseHeaderTimeout≤ 5s，否则 Go 模块下载器会在收到 200 后继续等 body 流，而 proxy 可能因 GZIP 压缩卡住
真正难调试的是“看起来没网络操作却卡住”的构建流程——往往藏在 go:generate 或第三方 build tool 里。建议在 CI 中统一加 timeout 60s 包裹所有 go 命令，并用 strace -e trace=connect,sendto,recvfrom 抓系统调用确认是否真有网络行为。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
