go mod download 在虚拟机中卡住主因是环境变量未被 go 子进程继承、goproxy 缺少 ,direct 导致私有模块 404、dns/tls 握手慢于宿主机；需在虚拟机内执行 go env -w 配置并验证 curl 请求地址。
go mod download 在虚拟机里卡住，基本是代理没穿透进去
虚拟机里 Go 模块拉取慢，不是宿主机配好了就自动生效——子进程（比如 go mod download）根本读不到宿主机的环境变量。你看到 go env GOPROXY 输出正确，但实际请求仍打向 https://proxy.golang.org/，就是因为 Shell 启动的 Go 进程没继承到变量。
- Linux/macOS 虚拟机：必须在虚拟机内部执行
go env -w GOPROXY=https://goproxy.cn,direct，不能只在宿主机设 - Windows WSL 或 Docker Desktop 中的 WSL2：检查是否用了 systemd 初始化，
~/.bashrc或~/.zshrc里的export GOPROXY=...可能不被 GUI 终端或 VS Code Remote 自动加载，要加到~/.profile - VMware/VirtualBox 共享文件夹场景：如果用
go run直接跑宿主机代码，Go 工具链仍走虚拟机自己的环境，和宿主机无关
为什么 go env -w 配了还是走默认代理
常见错觉：在虚拟机终端里敲了 go env -w GOPROXY=...，再 go env GOPROXY 看输出是对的，但 go mod download 日志里仍是 GET https://proxy.golang.org/。这不是命令失败，而是 Go 进程启动时没读到该配置。
- 验证方式：运行
go mod download -x github.com/gin-gonic/gin@v1.9.1，看第一行 curl 请求地址是不是goproxy.cn - VS Code Remote 或 JetBrains GoLand 连虚拟机时，IDE 自带的 Shell 环境可能没加载你的
.bashrc，需在 IDE 设置里显式添加环境变量 - 某些 CI/CD 脚本（如 GitHub Actions 的
ubuntu-latestrunner）默认不读用户级go.env，得用env:显式注入GOPROXY
,direct 漏掉会导致私有模块 404，尤其在内网虚拟机
虚拟机常部署在公司内网，依赖 GitLab、Gitee 私仓或自建 Nexus。如果只设 GOPROXY=https://goproxy.cn，没有 ,direct，Go 就会把 git.internal.company.com/my/lib 这类路径也发给 goproxy.cn，结果 404 —— 它压根不认识你内网域名。
- 必须用逗号拼接：
go env -w GOPROXY=https://goproxy.cn,direct - 配合
GOPRIVATE：运行go env -w GOPRIVATE=git.internal.company.com,github.com/my-org，让 Go 明确知道哪些路径跳过代理 - 注意：通配符
*不支持，git.internal.company.com/*是无效写法，只能写精确域名或路径前缀（如git.internal.company.com/my）
虚拟机 DNS 和 TLS 握手比宿主机更慢，别只盯着代理
很多虚拟机（尤其是 NAT 模式）DNS 解析慢、TLS 握手超时，导致即使代理地址对了，go mod download 仍卡在 dial tcp 阶段几十秒。这不是代理问题，是底层网络栈行为。
- 临时验证：手动执行
curl -v https://goproxy.cn，看是 DNS 卡住还是 connect 超时 - 强制系统 DNS：运行
go env -w GODEBUG=netdns=cgo，让 Go 调用系统解析器，避开自带的纯 Go DNS 实现（它在某些虚拟网络下更慢） - 如果虚拟机开了防火墙（如
ufw），确认出站 HTTPS（443）没被拦截：sudo ufw status
,direct 有没有兜住私有路径、DNS/TLS 层有没有被虚拟网络拖慢——这三个点漏一个，下载就会退回到默认代理，白配。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
