根本原因是虚拟机默认DNS（如127.0.0.53）解析失败或TLS握手卡住，需改用可靠DNS（如223.5.5.5）、设GOPROXY=https://goproxy.cn,direct、禁用IPv6，并隔离GOROOT/GOPATH避免并发冲突。
虚拟机里装 Go 为什么 go mod download 总失败
根本原因不是网络差，而是虚拟机默认的 DNS 和代理策略让 proxy.golang.org 解析慢或 TLS 握手卡住。尤其 VMware NAT 或 VirtualBox 默认 DHCP 分配的 127.0.0.53（systemd-resolved）在虚拟环境中常缓存失效、返回空响应。
- 先执行
cat /etc/resolv.conf，若看到nameserver 127.0.0.53，立刻换掉：用echo "nameserver 223.5.5.5" | sudo tee /etc/resolv.conf - 设代理必须带
direct后缀：export GOPROXY=https://goproxy.cn,direct，否则私有模块拉不到 - 别信
ping proxy.golang.org成功就代表能通——它只走 ICMP；用curl -v https://proxy.golang.org看是否卡在* TLS handshake - 如果仍超时，临时关掉 IPv6：
echo 'net.ipv6.conf.all.disable_ipv6 = 1' | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
多用户共用虚拟机时 GOPATH 必须隔离到家目录
共享 /usr/local/go 看似省事，但 go mod download 的并发写入会损坏 $GOCACHE，且 go install 输出二进制到 $GOBIN 若没隔离，不同用户可能覆盖彼此工具。
- 每个用户独立解压 Go 到自己家目录：
mkdir -p ~/local/go && curl -sL https://go.dev/dl/go1.22.5.linux-amd64.tar.gz | tar -C ~/local -xzf - - 显式导出三变量（不能只靠默认 fallback）：
export GOROOT=$HOME/local/go、export GOPATH=$HOME/go、export GOBIN=$HOME/bin -
$HOME/bin要提前加入PATH，否则go install gopls@latest装完找不到命令 - 绝对禁用
go env -w—— 它写入的$HOME/go/env是纯文本，sudo 错误写入后所有用户都继承，排查极难
静态编译 + scratch 镜像防止沙箱越界访问
普通 Docker 镜像含完整 libc 和 shell，一旦容器逃逸，攻击者可用 /bin/sh 或 ldd 探测宿主机环境；而 Go 静态编译配合 scratch 基础镜像，能彻底移除攻击面。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 编译时加
-ldflags '-s -w'去符号表，再用CGO_ENABLED=0 go build -o myapp .强制静态链接 - Dockerfile 用
FROM scratch，只 COPY 二进制和必要配置文件（如 TLS 证书），不带任何系统工具 - 启动时指定非 root 用户：
RUN adduser -u 1001 -D appuser && chown -R appuser:appuser /app，再USER appuser - 验证是否真静态：
ldd myapp输出not a dynamic executable才算过关；若提示libc.so.6，说明 CGO_ENABLED 没关干净
Kata Containers 运行 Go 应用时 runtimeclass 配置要点
Kata 不是“换个镜像就行”，它依赖 containerd 正确识别 io.containerd.kata.v2 运行时，且 Go 应用需适配轻量 VM 启动延迟 —— 比如健康检查 timeout 要从 5s 改成 30s。
立即学习“go语言免费学习笔记（深入）”；
- 确认 Kata 已安装并注册：
ctr runtime list | grep kata应输出io.containerd.kata.v2 - containerd 配置中
/etc/containerd/config.toml必须包含对应[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata]段，并设runtime_type = "io.containerd.kata.v2" - Kubernetes 中定义
RuntimeClass时，handler字段值必须与 config.toml 中的 runtime 名称一致（如kata） - Pod spec 里加
runtimeClassName: kata，但别忘了资源 request/limit 要比普通容器多 30% —— Kata 启动开销大，CPU limit 设太低会导致 init 容器卡在ContainerCreating
实际部署时最容易被忽略的是：Kata 容器内 /proc 和 /sys 是隔离视图，Go 应用若调用 os.ReadDir("/proc") 或依赖 /sys/fs/cgroup 获取内存限制，会读到 Kata VM 内部的伪路径，而非宿主机真实 cgroup —— 这类逻辑必须改用 resource.NewClient().GetMemoryLimit() 等标准接口。
