桥接模式让虚拟机成为局域网独立节点，可直连GitHub等外网资源；NAT模式需依赖宿主机代理或端口转发，否则go get会超时。
虚拟机跑Go开发环境，最低2核CPU + 2GB内存够用，但网络必须设为桥接或NAT+端口转发，否则go get会卡死或超时。
虚拟机资源分配：别被“推荐配置”带偏
很多教程写“建议4核8GB”，实际纯Go命令行开发，2核2GB完全不卡。重点不是堆资源，而是避免两个坑：
- 内存低于1.5GB时，
go build在编译大型依赖（比如golang.org/x/tools）可能触发OOM killer杀掉进程，终端直接断连 - CPU给1核也勉强能跑，但
go test -race会极慢，且并发测试容易假死——这不是Go问题，是虚拟机调度没资源可分 - 硬盘别用动态扩容镜像，尤其是CentOS 7默认的qcow2格式，
go mod download大量小文件IO时磁盘I/O延迟飙升，表现就是go命令卡住10秒以上才响应
网络模式选桥接还是NAT？看你要不要go get外网模块
结论很直接：要拉GitHub、Go Proxy、私有GitLab上的包，必须桥接；仅本地编译运行，NAT够用。但注意：
- 桥接模式下，虚拟机IP和宿主机在同一网段，
go get github.com/sirupsen/logrus直连无压力，但换WiFi后IP变，得手动systemctl restart NetworkManager（CentOS）或sudo systemctl restart systemd-networkd（Ubuntu） - NAT模式下，
go get默认走宿主机代理，如果宿主机开了科学上网工具（如Clash、Surge），虚拟机里export GOPROXY=https://goproxy.cn就能通；但若宿主机没代理，go get会卡在Fetching https://proxy.golang.org/...直到超时 - VMware用户注意：
vmnet8（NAT网卡）有时会被Windows Hyper-V抢占，导致DNS解析失败——现象是ping goproxy.cn通但curl https://goproxy.cn超时，关掉Hyper-V或换VirtualBox可解
GOROOT和GOPATH路径写错，go命令就找不到自己
常见错误不是变量名拼错，而是路径层级和权限错位：
立即学习“go语言免费学习笔记（深入）”；
-
GOROOT必须指向/usr/local/go（解压后的真实目录），不能是/usr/local/go/bin——后者会导致go env GOROOT输出正确，但go build报cannot find package "fmt" -
GOPATH别硬塞到/root/go，尤其当你用普通用户（如devuser）开发时：sudo chown -R devuser:devuser $GOPATH漏了，go mod init会静默失败，后续go run提示no required module provides package - 环境变量写进
/etc/profile看似一劳永逸，但Zsh用户（如Kali默认）根本读不到——得改~/.zshrc，且source ~/.zshrc后必须新开终端，旧终端里的$PATH不会自动更新
验证环境是否真可用，绕过“hello world”陷阱
只跑go run main.go成功不代表环境OK。真实踩坑点在模块管理：
- 执行
go mod init example.com/hello && go get github.com/google/uuid，卡住超过30秒就是网络或代理问题 -
go list -m all应列出github.com/google/uuid及版本，如果只显示example.com/hello，说明go.mod没生成或GOPATH不在当前路径下 - 用
go version -m ./main.go看二进制是否嵌入模块信息，如果输出空白，大概率是go命令调用的是系统包管理器装的旧版（如Ubuntu的golang-go包），而非你手动解压的/usr/local/go
最常被忽略的其实是Shell初始化顺序：~/.bashrc里写的export，在非交互式SSH登录（比如用Xshell连）时根本不会执行——得把环境变量挪到~/.profile，或者确认SSH服务配置了PermitUserEnvironment yes并启用~/.ssh/environment。
